Partitioning criteria revision proposal

[Adam Williamson]

On Wed, 2012-10-10 at 22:31 -0700, Adam Williamson wrote:
> Hey, folks. So it became clear over the course of the last few blocker
> reviews that the new partitioning criteria need a bit of refinement.
> Here is my proposal for altering them.

So...aside from the specific discussion of my proposals, I was thinking
some more in general about the design of the partitioning criteria, and
I'm starting to wonder if we're maybe getting too ambitious in terms of
what we require at Beta, especially compared to previous releases.

So if we go back again and look at how things were before, here is what
we required:

At Alpha, the offered autopart mechanisms except for 'shrink' had to
work: this covered wiping entire disks and autoparting into the empty
space, wiping only Linux partitions (preserving Windows ones) and
autoparting into the empty space, and autoparting into existing empty
space. It also covered LVM and non-LVM, and encrypted and non-encrypted,
variations on autopart, as these were offered on the autopart screen. We
did not require anything from custom partitioning.

At Beta, we added a requirement that the installer be able to install to
hardware and BIOS RAID arrays, and create and install to software RAID
arrays (softRAID is a function of custom partitioning; this is the only
thing we required to work in custom partitioning at Beta).

At Final, we basically required any viable partitioning scheme to work
(by implication and policy, custom partitioning issues were all
considered Final blockers, aside from softRAID).

So, we only required softRAID functionality from the custom partitioning
bit at Beta; all other requirements for custom partitioning were Final.

Now with F18 Alpha 'autopart' was very very basic so we kind of got the
idea that we'd have to require more custom part functionality to work at
Alpha and Beta, and we've been working on that basis so far. But taking
a step back and looking at it, the 'guided partitioning' flow in F18
Beta is much more capable and nearly matches what autopart in F17
offered. Without going into custom partitioning, you can autopart into
empty space, or wipe any combination of existing partitions if you do
not have sufficient free space. You can also encrypt the installation,
now. There's only really two things missing:

a) you can't wipe or shrink partitions if you have sufficient free
space, even if you want to (to provide *more* space for the install) -
you have to use custom partitioning if you want to do this

b) you can't do LVM without going into custom partitioning

but that's *all*. Everything else you could do with autopart in F17, you
can do with 'guided partitioning' in F18. So I'm not sure the approach
we're currently working on, of requiring extensive functionality from
the custom partitioning tool at Beta time, is necessarily warranted. We
could still decide we want certain things to work in custom partitioning
at Beta time, but we don't really have to just in order to maintain the
standards from previous releases, it would really constitute *raising*
our standards.

So I'd be interested in general opinions about whether we should go down
the path of requiring quite a bit of reliability from custom
partitioning at Beta stage, or whether we should perhaps dial that down
a bit, and only really require extensive functionality from custom
partitioning at Final stage, as we did for F17 and earlier. I'd
especially be interested in what the anaconda team thinks, so could you
folks chip in?

Once there's a clear consensus about which general path to take, I'll go
back to specific proposals, trying to incorporate the feedback to my
last attempt. Thanks!

BTW, on the topic of LVM specifically (whose importance we still haven't
really established): I did some archive-diving last week. We first went
to LVM-by-default all the way back in Fedora Core 3. There were two
reasons for doing this. The 'official' one was to make it easier to
expand the capacity of a system simply by adding another hard disk. The
less official reason was to get more testing of LVM, which was still in
its infancy at the time. Ever since then, we've stuck with the default
really just because it's always been there; until I started poking into
it, no-one really had a story for why LVM was default any more.

Neither reason really applies much any more. LVM is much more mature
now, and in a way is yesterday's news, the Glorious Future maybe belongs
to btrfs. And we've finally hit the point in history where most people
don't run out of space on the hard disk that comes with their system,
and even when they _do_ run out of space, it's usually not with OS data
but with 'user data' that is much easier to spread across multiple disks
without using LVM. So I'm not sure we really have a convincing reason
any more to care especially about LVM.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net