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. The current Beta partitioning criteria are provided for reference: current ------- * The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched * The installer's custom partitioning mode must be capable of the following: ** Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ** Creating encrypted partitions ** Rejecting obviously invalid operations without crashing * The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot Here are my proposed changes. proposed -------- * The installer must be able to complete an installation to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched, without using the custom partitioning mode * When there is not sufficient free space for installation, the installer must allow the user to selectively remove existing partitions without using the custom partitioning mode * The installer's custom partitioning mode must be capable of the following: ** Creating and, optionally, encrypting partitions of any specified size using all offered device and filesystem types ** Assigning mount points to newly-created partitions ** Using an existing partition as the /home partition for the installation without reformatting it ** Deleting any existing partition ** Rejecting obviously invalid operations without crashing To break down the changes here... Referring to 'automatic partitioning' was meant to talk about the 'help you free up space' workflow, but it's a bit confusing as there's an 'automatic partitioning' option *within* custom part now. We could give a name to the 'help you free up space' process and refer to that, but it seemed easier just to say 'without using custom partitioning'. The basic theory here is we're requiring certain functionality from the 'help you free up space' workflow and also certain functionality from the 'custom partitioning' workflow. It seemed prudent to specifically require that removing partitions selectively in the 'help you free up space' workflow must work at this point. The previous Alpha and Beta criteria that we worked up didn't exactly cover this: if the non-custom workflow could only completely wipe disks or install into free space at Beta stage, it would have passed under the old criteria. It was pointed out that the 'Creating, destroying and assigning mount points' wording had the effect of requiring re-use of existing partitions at Beta to work, which wasn't really intended. The revision attempts to be more clear about precisely what has to work at Beta: really just 'creating a new partition layout' and 're-using /home', which is a specific subset of 're-using existing partitions' that we have reason to care about. This is a debatable point - we could potentially require more in the way of existing partition re-use at Beta. But I thought we'd start with just that case as a starting point. If anyone has a convincing case for requiring more re-use cases (with or without reformatting) to work at Beta, do speak up :) We agreed at the blocker review meeting this morning that "most commonly-used filesystem types" was really pretty vague and unsatisfactory. The specific case we were considering was LVM. In the end we agreed that, really, at Beta stage, anaconda ought to be capable of dealing with any filesystem / device type it offers (the 'device types' are LVM, RAID and btrfs). If a type isn't working it needs to be either fixed or suppressed (as we did for the last couple of oldui releases with btrfs - we suppressed it from the list as it wasn't working). The intent here isn't to cover every possible bizarre permutation anyone can come up with (the Final criterion does do that), but more that just simply creating a partition in a pretty normal, everyday way with any of the options offered shouldn't cause the installer to fall over and die. Please, anaconda folks, if you think this is too optimistic and you think we should exclude specific types or limit the criterion to a specific subset of types, yell. The specific RAID criterion seems to me to be pretty much subsumed in the above proposals, so it can be dropped. It's worth noting that we're still using the old 'The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above' criterion for Final. I think this is not entirely optimal; the scenario dcantrell proposed in the 'criteria review' thread, for instance, would technically be covered by this. But revising it would be very difficult, I think, because all you can really do is either write a *giant* laundry list of use cases in the 'custom partitioning should be capable of' format, which is ugly and horribly non-scalable, or wave a white flag and say 'partitioning issues are subjective and we'll just deal with them case-by-case'. Those are the only options I can come up with, anyway. If anyone has a neat idea for improving the final criterion, please do propose it, because I'm damned if I can. :) This is tricky stuff so I may well still be missing something, please do take a close look at the proposal and point out any issues. thanks! -- 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
