F19 Final criteria revamp

[Kamil Paral]

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

Thanks a lot, I reviewed them and they seem to be fine. Some comments below.

I noticed that the upgrade criterion went missing. But we already have one in Beta, and it seems to be the same. What am I missing?

> * 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).

The "unless they require hardware which is not present" phrase could be separated into a comment box, so that the original sentence is cleaner. Just an idea.


>  SELinux and crash notifications
> There must be no SELinux denial notifications or crash notifications after boot of a release-blocking live image or at first login after a default install of a release-blocking desktop. 

Should we add "during installation" as well? Wrt the bug discussed in the last blocker bug meeting.

> 
> * 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 agree. These issues were too trivial to block release on. Still, I'd like to see /someone/ to ensure the polish. It would be great to have both QA team and Polish (UX) team. At present, we need to handle that. But this change is fine. I'm looking forward to simplifying the test cases.

> 
> * 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.

" All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." 

Maybe "must not be inconsistent"? They are hardly consistent now. Plymouth theme is the same for years, GDM background has nothing to do with desktop background.

Maybe drop the sentence completely?