F19 Final criteria revamp

Adam Williamson awilliam at redhat.com
Wed Jun 5 04:55:43 UTC 2013


Hey folks - so just ahead of the blocker meeting tomorrow, I'm done with
the Final criteria rewrite.

For now I've put it in a 'sandbox' space because I did make a few
changes on-the-fly and they should get reviewed before we replace the
old page, but if people think it's a good idea, we can use them for the
meeting tomorrow.

Here's the new version:

https://fedoraproject.org/wiki/User:Adamwill/Draft_final_criteria_sandbox

The current one is of course at
https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria for
comparison.

Most of the changes I made are fairly minor tweaks to make the meanings
more robust and stuff, but here's some more significant things I thought
it made sense to change:

* I made the 'checksum verification' thing a lot simpler; the existing
one was written in two stages which made it read more complicated than
it really needed to be.

* I re-worded the 'catch-all' partitioning criterion to refer to "any
file system and/or container format combination offered in a default
installer configuration". It doesn't really make a functional difference
I don't think, it just reads more clearly and is more 'future-proof'.

* We were covering bootloaders in a half-assed way in the Windows dual
boot criterion, but that seemed kinda dumb, so I figured it would make
sense to break out an explicit bootloader criterion: "The installer must
allow the user to choose which disk the system bootloader will be
installed to, and to choose not to install one at all." In practice
that's basically what we required to work for F18.

* I 'cloned' the translation criterion for the installer; we were really
intending the installer to be covered by the existing criterion, but it
really wasn't clear in the wording. This way seemed more clear.

* I wrote an exception for hardware-based services when the hardware
isn't present into the 'services' criterion: we waived a couple of
'blockers' for F18 on the basis that it's okay if a service fails if
it's for hardware that isn't present, so I thought it made sense to
write that into the criterion. (Obviously it's best if we can make the
service not fire unless the hardware is present, but I don't think it
makes sense to block the release on that kind of thing).

* I watered down the 'desktop' criteria quite a bit. Looking at them
afresh I really think we were kind of over-reaching when we wrote them
for F13: I remember we were thinking about 'polish criteria', but now
we've had this process in place for a while, it really doesn't make
sense to block the release on fairly trivial 'polish' issues (especially
when we happily ship with much bigger issues in slightly different other
areas). So I nuked the 'icons can't be fuzzy' requirement, the
requirement for Help and About menus to be present, and the bit about
apps not showing up twice in the menus. Those are all nice things to
check, but I really don't think we need to be blocking releases on them.

* I watered down the artwork criterion yet further: the initial idea was
that we were going to be super-keen about having a consistent background
graphic from bootloader to desktop, but that's really fallen by the
wayside since F14 or so. Given our overall boot process nowadays, it
only seems particularly important to make sure we use the right image
for the desktop background. It'd be great if the project goes back to
that goal, but clearly so far there hasn't been the development
commitment to keep it going.

Hope that covers everything! Yell if there's a change you can't see the
reason for, and of course, all normal
suggestions/improvements/questions/whatever welcome. Thanks folks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the test mailing list