Second draft of revised final criteria, proposed criterion for partition resizing

Adam Williamson awilliam at
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 
badly broken.


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.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | adamwfedora

More information about the test mailing list