[criteria update]

[Adam Williamson]

On 2012-09-11 6:39, Petr Schindler wrote:
> On Čt, 2012-09-06 at 10:01 -0700, Adam Williamson wrote:
>> On 2012-09-06 0:58, Petr Schindler wrote:
>> > Hi,
>> >
>> > I think that require LVM and encryption in alpha phase is quite 
>> too
>> > early. It isn't feature which should slow down the alpha release. 
>> I
>> > propose to demand it in beta phase. So I propose to change alpha
>> > criterion:
>> >
>> > 'The installer must be able to complete an installation using the
>> > entire
>> > disk, existing free space, or existing Linux partitions methods, 
>> with
>> > or
>> > without encryption or LVM enabled'
>> >
>> > to:
>> >
>> > 'The installer must be able to complete an installation using the
>> > entire
>> > disk, existing free space, or existing Linux partitions.'
>> >
>> > I think, that these three options are reasonable for alpha. This
>> > doesn't
>> > say anything about how to do it, only what should be possible, so 
>> it
>> > could be used with the new anaconda.
>>
>> I think that's going in the right direction, though possibly not far
>> enough. It's worth bearing in mind that the existing criterion is 
>> very
>> tied to the old UI design: "Entire disk", "Existing free space", and
>> 'Existing Linux partitions" are direct references to the various
>> autopart methods that oldUI presented, and encryption and LVM are in 
>> the
>> criterion precisely because they were the two checkboxes available 
>> on
>> the oldUI autopart dialog. Basically, the criterion was written to
>> encapsulate the idea 'all the options on the autopart screen should
>> work'.
>>
>> Given that, it's probably better just to write something entirely 
>> from
>> scratch that's appropriate to newUI rather than trying to tweak the
>> existing text...
>
> OK, what about something like:
> 'The installer must be able to create a reasonable disk layout using
> entire disk or enable to create custom layout using basic file 
> systems
> (ext4, swap)'
>
> It's only draft, so I'd like to hear your comments and objections.

So, here's some more data, from talking to the anaconda team yesterday.

The current behaviour of newUI is this:

If you pick a disk or disks, and they're big enough to install to, and 
you don't click the misleadingly named 'review' button, anaconda will 
entirely wipe all the selected disks and re-partition them how it likes. 
Essentially, like the 'use entire disk(s)' option from oldUI.

If you do click the misleadingly named 'review' button, you wind up in 
custom partitioning - this is the way you access custom partitioning 
now. You can theoretically do just about anything here, just like old 
custom part. (If you can figure out the UI). It has a 'create partitions 
automatically' button, which will try to autopart within any available 
free space (it will not delete any existing partitions for you).

So we don't really have the nice split between the 
still-fairly-featureful autopart screen and custom partitioning like we 
did in oldUI, which we took advantage of for the criteria. If we don't 
require any functionality from the 'custom partitioning' interface at 
Alpha, and anaconda team doesn't change the design, then the only thing 
we're guaranteeing will work at Alpha is 'wipe out at least one entire 
disk' - we won't be guaranteeing any kind of non-destructive install.

This is still a plausible path to take, but we'd need to take it 
consciously. If we'd rather require _some_ more functionality than that 
at Alpha, we'll have to phrase it generically and it'll involve testing 
the custom partitioning module.

Personally, I can kind of see the argument for only requiring the 
destructive autopart option to work, even though it sounds pretty 
barebones. It _is_ only an Alpha, after all, and we specifically say 
that it should be installed to a disposable test environment, not to a 
production system. So I suppose I'd propose a very simple criterion for 
Alpha:

"The installer must be able to complete an installation using automatic 
partitioning to any sufficiently large target disk, whether unformatted, 
empty, or containing any kind of existing data".

We could require further functionality from the custom partitioning 
module at Beta and Final.

However, there could be reasonable arguments why we should require some 
functionality from the custom part module, so if you can think of some, 
please do...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net