Second draft of revised final criteria, proposed criterion for partition resizing
awilliam at redhat.com
Wed Jul 3 23:47:06 UTC 2013
Hi folks! Taking into account the feedback on the first draft of the
revised criteria, I've updated the draft page with a few changes:
I updated it to F20 status first of all. Then I re-worded the AVC/abrt
criterion to cover live installation, as we want to cover that. It now
"There must be no SELinux denial notifications or crash notifications on
boot of or during installation from a release-blocking live image, or at
first login after a default install of a release-blocking desktop."
For the 'single partition' issue with the Windows criterion I simply
dropped the single partition reference entirely, that seemed like all
that was necessary. The remaining 'caveats' should be strong enough to
allow us not to block for crazy cases.
I considered the suggestion to make the "unless they require hardware
that is not present" bit of the 'services must work' criterion a
sub-section, but on balance I don't like it: the sub-sections are really
meant to _explain_ the main criterion, not fundamentally alter its
meaning. I did use it to list exceptions a few times, but this one just
seems like too big of an exception: it really is a part of the main text
of the criterion, I think, it doesn't belong as a sub-section. So I left
that as it is.
I'd also like to consider adding a criterion that covers resizing, as
discussed in the long thread about dual-booting. I think we can add a
minimal criterion that's realistically enforceable if we word it right.
Let's make that a proposal here on the list, rather than part of the
'revision' draft, though. So, here's my proposal:
Any installer mechanism for resizing storage volumes must correctly
attempt the requested operation.
Sub-section "What does that cover?":
This means that if the installer offers mechanisms for resizing storage
volumes, then it must run the appropriate resizing tool with the
appropriate parameters for the resize the user chooses. The reason it's
worded this way is we specifically ''don't'' want to cover cases where
the requested resize operation then fails for some reason - dirtily
unmounted or over-fragmented partition, for instance - then fails. We
only want to cover the case that the installer's resize code itself is
Any comments on that criterion proposal or the revised Final criteria
draft would be most welcome! Thanks folks. I'm aiming to have this
rounded off fairly soon so I can move on to other F20 prep work.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
More information about the test