Fedora Installation Guide Schedule

[Paul W. Frields]

Portions of a conversation Stuart and I have been having offlist WRT the
Fedora Installation Guide:

On Sat, 2005-03-05 at 18:29 +0000, Stuart Ellis wrote:
> > There are significant sections on RAID and LVM that (I think) are pretty
> > much required, so that a new user can figure out how to set them up.
> 
> Very much agree.  I don't think that we can reasonably say that LVM is
> just an advanced option any more, even if it's a pain to document. 
> Having mind-bending amounts of less reliable storage available for
> peanuts makes these technologies pretty much mandatory...

That said, I think that many hobbyists (and I'll put myself in among
them) still tend to use physical partitions as "directly formatted"
ext3. I'm not planning on adding and removing disks on my home
workstation, and neither are many users. Nevertheless, you and I are in
complete agreement that RAID/LVM must be fleshed out in the installation
guide... especially since anaconda uses LVM for automatic partitioning
these days.

> > If I have to sacrifice those sections to get this thing out for FC4
> > test2, I will, but I will keep working on them nonetheless. 
> > I am currently using FC3 to do my writing, but I will have FC4 test1
> > (almost) as soon as it is issued.
> 
> This was really what I felt we needed to work out - there's enough stuff
> in the TODO to keep Mayank and I busy until you are ready, and IMHO it
> helps if we all stick to the same version (whether it's the latest or
> not).  If you are happy to move up to test 1 then I'll do a roll-up
> release and switch development after test 1 comes out, with a new target
> of test 2 for a public beta release.  What worried me was the risk of
> things drifting or getting into a muddle later if we didn't agree
> something at this stage.

Mm, hadn't thought enough about the ramifications, you're right. Look, I
think it would be much easier to stick with FC3 until FC4 final is
issued. I know that means we might be "off target" for a week or two
until we update, but it's easier than trying to "track" changes between
FC3, FC4t1 and FC4t2 -- just in case anaconda has some niggling change
between test releases.

> > You can see what I've done at http://svn.frields.org if you are interested.
> 
> OK, I've read through them, but won't make any nit-picky comments since
> they're works in progress.  Following from the above, though, it might
> be worth assuming that LVM is the standard way of doing a manual
> partition layout, and push that further up the text, perhaps even
> deprecating directly partitioning the drives (just a thought - I don't
> know if this is entirely reasonable).  As a parallel, I ended up
> deprecating static IP addressing for anything other than servers,
> because I realised that it wasn't actually the best approach in most
> scenarios any more (NetworkManager, plus cheap DHCPing routers and WAPs
> all over the place).

See my comments above; 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. 

However, injecting a discussion of LVM (or RAID) into the procedural
flow about how to use the anaconda installer is a bit distracting,
though. These sections exist to backstop the installation process rather
than to push people toward a technology. They are enabling technologies
for the situations that call for them. I'm not sure which version you
saw and what I'd completed by the time I'd emailed you. Right now I plan
on making frequent calls to the RAID and LVM subsections using <xref>
where called for, and I think that will make everyone comfortable when
they read it.

> Another vague suggestion is that the Appendix might be easier to tackle
> by structuring it around the use cases (workstations and laptops would
> be probably use Automatic partitioning, or just have a separate /home)
> and maybe de-emphasising the hardware specifics.  Most servers and
> workstations I've seen use IDE CD drives with SCSI hard drives and
> tapes, or (recently) just SATA.  (S)ATA RAID is apparently now fairly
> common on enthusiast mainboards too, so I guess that the boundaries are
> getting very blurry.

Many legacy boxes are being coverted to Linux, however... which really
proves your point. That's why I would like to de-emphasize the "let's
explain technology" angle, and instead focus on the procedure first and
foremost, referring to specific sections on enabling technologies where
appropriate.

> FWIW, I've written up a documentation plan to try to summarise for
> Mayank (and any future contributors) the aims and requirements I've been
> working towards with the text:
> 
> http://www.mythic-beasts.com/~hobb/main/index.php?pagename=InstallationGuidePlan
> 
> The current version is just a brain dump - comments and corrections are
> very welcome.

This is good info for anyone trying to contribute to the IG. One thing
that occurred to me while reading: I think that relying on the built-in
help screens of a program is not a commonly accepted method for doing
system documentation. It definitely saves a little time, but in terms of
a readable document, simply providing extra material in the absence of
the basic procedural support is going to result in a document that's
much harder to read. There's nothing wrong, for example, with simply
reproducing what's already in anaconda in the IG, as long as the
terminology is supported and the style is consistent. We have a couple
documentation experts at work whom I will ask this question if I can get
them off the keyboards long enough.

-- 
Paul W. Frields, RHCE