My original mail ended up being very long, so I'll try to do better and keep my comments to a readable length: - Release schedule, and what version(s) of FC to write against: My main concern is to minimise the workload for everybody, so I'm happy to fall in line with whatever arrangements other people feel are best for their writing, editing etc. Probably sounds customer-unfriendly, but the users can only be helped if we can produce and maintain a complete doc with the resources that we have. What I'd personally like is secondary, but ideally would be: - To release a credible-looking test document for feedback, and to attract more contributors (hopefully some that can test against x86-64 and PPC). Credible may mean FC4 test 1 at this point, I don't know. - To complete a 1.0 draft in time for it to be edited, so that... - An Installation Guide for FC4 appears as soon as possible after FC4 final is released. - To have a 1.0 Guide for FC3, if Karsten is willing to edit two documents. The reasons for the last are that many people are very slow to upgrade (I'm still having to try to persuade people on forums to get off RH9), and that I think that it would be useful to start figuring how to practically support multiple versions as soon as we can. - Installation Guide Plan, and Anaconda vs. Installation Guide: http://www.mythic-beasts.com/~hobb/main/index.php?pagename=InstallationGuidePlan One of the (many) ideas that I've tried to compress into the "plan" is that an Anaconda graphical installation is kind of self documenting already, in that you can read the screens and understand what to do *if* you speak Linux and understand the terms that are used. Which suggests that a lot of the value of the Installation Guide is in explaining what the options mean, and describing the features that can't be seen on the graphical screens. I wouldn't like to have sections which just repeat the contents on the screen without adding anything - this isn't very well expressed. I'd be very interested in hearing how professional documenters link program screens with the documentation - I don't think that the current layout quite gets this right. - Recommending LVM and deprecating direct partitioning: > I still think LVM is not a requirement for an > installation just because the installer uses it in the "autopilot" mode. > It does that in order to support a broader base of administrators who > don't know yet that they might want LVM. As a consequence the guide must > address LVM. This was really my point in a nutshell - IMHO everybody who manually partitions a drive ought to use LVM, even if they don't realise it when they install the system. At work we now mandate the MS equivalent of LVM on all Windows servers because we discovered in testing that it was impossible to guess exactly the right partitioning setup for 100Gb+ of storage in advance, and destructive repartitioning is, well, not a valid option once a system is live... > However, injecting a discussion of LVM (or RAID) into the procedural > flow about how to use the anaconda installer is a bit distracting, > though. Yes, thinking about it these concepts are advanced however you document them (manual partitioning is probably an advanced topic, as a whole), so probably ought to be pushed out to an Appendix as much as possible. The only reason that I routinely go through the manual partitioning on workstations is get /home away from the root partition. -- Stuart Ellis
