Fedora 23 Final RC10 status is GO !

[Michael Catanzaro]

On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote:
> Peter Robinson wrote:
> > The problem is we have to freeze sometime to ensure stability in
> > the
> > installer platform, the live and other images which are static. If
> > not
> > it's too much of a moving target to try and QA and ensure
> > everything
> > works as expected. To freeze is a fairly standard procedure for all
> > distro development.
> 
> IMHO, we should have at most 1 week of strict freeze. If we decide
> that we 
> have to slip anyway, then we should pull in ALL updates pending
> stable and 
> restart the release process (freeze, spin RCs, test) from there.
> 
> (That would also make it less painful to slip multiple times and thus
> decrease the pressure to rush out quick hacks to work around blockers
> instead of clean fixes.)

I think Kevin is closer to right on this. It's unreasonable to have 500
updates queued for users on release day. Yeah, freeze is required to do
QA on the release, but QA on the release is not worth so much if it all
goes out the door the first time someone clicks update. (Well, it's
essential for the installation process, but beyond that....)

I will say: Fedora has the *best* release QA *by far* of any comparable community distro -- maybe even better than Debian! -- but we all know our updates break things all the time. In F22, we had at least two (I think actually three, but I lost count) separate updates that broke the ability to apply further (PackageKit) updates. Come on! We have to fix this for OEMs to have any confidence in shipping Fedora. (At least, I'd like to see Fedora in stores, and I think I'm not the only one....)

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

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.

> I also think that the decision:
> * when an image is a Go,
> * what issues to consider as blockers and
> * what new builds to take as freeze overrides
> ought to be made by the WG/SIG responsible for the individual
> deliverable. 
> (And this is NOT a personal power grab attempt. I am no longer a
> voting 
> member of the KDE SIG, for reasons detailed on the kde mailing list.)
> The 
> current process where the SIG/WG has to argue for every single freeze
> override they want to take in, and have rel-eng/QA reject some of
> them, is 
> just broken (and there I can speak from experience, with my 8 years
> of KDE 
> SIG involvement).

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.

Besides, they're the ones testing the thing.

Michael