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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
