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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
