Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

Michael Catanzaro wrote:
> My recommendation is the opposite of what Kevin would say, though. I'd
> like to see a third party responsible for giving final approval on all
> updates, charged with reducing the size of the updates pipe dramatically.
> Maintainers should not have final say on updates except in the event of a
> serious regression (in which case we need a revert button to skip
> updates-testing).

No thanks! If I wanted a distribution with such a strict control on updates, 
I'd use RHEL/CentOS, not Fedora! The fact that bugs actually get fixed in 
Fedora (whereas in conservative distributions, they often tell you to wait 
for the next release that comes months to years later) and that we even get 
new improved versions of applications is a huge advantage of Fedora, and 
also part of what Fedora is about (see "First"). Throwing it away would be a 
very bad idea.

I actually think we need a MORE update-friendly policy, where we recommend 
always pushing new versions unless there is a good reason not to. (The 
current policies are written the other way round, they recommend NOT pushing 
new feature releases unless there is a good reason to. I have been 
complaining about that right from the day it was written down.)

> An alternative we've been throwing around in the Workstation group is
> service packs (or "update packs") -- all non-security updates get bundled
> together, QAed, and released every 4-8 weeks. If you want to get your
> update out faster than that, you need a CVE or a special exception.

All that this accomplishes is delaying much needed fixes, it doesn't really 
solve any problem. It just creates new ones, such as dumping a huge set of 
updates on the user all at once, leading to bandwidth bottlenecks, and a 
higher risk of breakage on the flag days.

> Then we need to have separate release cycles for each product, since I
> don't want Workstation blocked indefinitely on everything
> Cloud/Server/KDE want to fix, and presumably those groups don't want to
> block on us... it's frankly annoying to me that we risk blocking
> Workstation on such issues, but it's a compromise we need to make to
> ensure the other releases are good. (And that vice-versa when the other
> releases get blocked on Workstation issues.) As long as we have four
> separate releases on the same cycle, it makes sense that QA gets final
> say.

This egoistical attitude is what is preventing us from shipping quality 
releases. The sky is not going to fall if your product/edition/spin gets 
released a couple weeks later. And with my proposed change to the release 
policy (slip = unfreeze, sync all updates, refreeze), you could also use the 
time to get fixes/improvements in that would have otherwise missed the 
release.

        Kevin Kofler