On Thu, 20 Nov 2003, Paul Pianta wrote: > Alexander Rau (work) wrote: > > >Here are my suggestions for a Table of Contents (TOC) > > > >Just a brain storm and working copy: > > > >1. Introduction > > > > > very nice and comprehensive TOC - good stuff. > > i just thought to myself .... > what is it that most people want to do when customizing > redhat/fedora/anaconda? > > these are some things i came up with that could maybe somehow be > incorporated into the doc ... > > * creating a single cd from the 3 cd set with a cutdown version of > packages and comps.xml and a kickstart file to automate the whole install > > * remove/replace all occurences of the words redhat/fedora from the > anaconda install process (text and graphical) with their own custom > text, logos, etc... > > * replace original redhat/fedora rpm packages with updated rpm packages > (security updates or whatever) and reburn the cds so that they can have > a version of RedHat 9 - six months after its release - with all security > updates applied (and other packages updated) > > * add functionality to anaconda that didn't previously exist - eg. > adding a new filesystem support, adding support for a new NIC, etc. > (this one is more technical and would be rather difficult to incorporate > into a generic anaconda doc.) (infact forget about this last one for > inclusion ...) > Actually, what is required documentation wise with this last one is something that at a high level describes the architecture of anaconda (how it all fits together, what python modules exist, what service they provide. Also, things like something that actually describes anaconda's install process from boot to re-boot). A lot of this actually would be usefull for not only extending anaconda, but also for things like troubleshooting installs and better understanding how to interact with it from a kickstart perspective (for instance part of its install process is it reads the kickstart file initially, and then it re-reads it after post. This is of course really usefull for making kickstarts that use %pre to essentially query the system and then tailor the kickstart after this to the specific needs at hand). On, the other hand actually document the actual api of the various python modules should definately not be a first pass thing (though, it certainly could be a goal). Anyway, I think your last category is ultimately still quite usefull when you look at it from the architectual perspective rather than just giving examples or specifics of how to add particular bits of functionality. Just by 2 cents. Cheers...james
