Refining the update queues/process [Was: Worthless updates]

[Kevin Kofler]

Seth Vidal wrote:
> And stages non-critical/important updates so our QA team can test and
> check them over more thoroughly and align testing goals and days to help
> foster and create a more active and involved testing infrastructure.

Congratulations for that sentence full of technical jargon designed to hide 
its true meaning.

* Who decides what updates are or are not "critical" or "important"? The 
criteria you brought up earlier in this thread (only security as critical) 
are way too restrictive, what about a fix for a regression?
* Why would the QA team be better off having to test everything at the same 
time for the same deadline than the current flow of testing updates?
* Why would we want to "align" our "testing goals and days"? It makes more 
sense to spread them so people can test one thing at a time!
* So would this really "create a more active and involved testing 
infrastructure"? IMHO it'd just create more painful deadlines, as if the 
releases weren't enough of a painpoint already.
* And most importantly, even if we were to accept that it could lead to 
better QA (which I doubt), would it really be worth making users wait a FULL 
MONTH for their updates and forcing them to pull a HUGE update in one single 
transaction rather than spread over time? IMHO, HELL NO!

Fedora is not RHEL, introducing an RHEL-style point release system is 
bizarre and IMHO quite silly.

> This is what we HAVE to do.

Why? Because you say so? We aren't doing that stuff now and things are 
working just fine, thank you very much! We don't HAVE to change anything at 
all!

        Kevin Kofler