[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Installation Guide Schedule

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

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:


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]