Yes, finally there’s an updated updates policy for Fedora.
I think it’s worth reading because, as the announcement says, it can be improved, clarified and adjusted; but it’s a very good starting point.
I was writing a more or less deep review of the document, but my internet connection failed, Chromium crashed (!), and here I am writing this post again, so instead of explaining something that you can read yourself in the policy page, I’m going to focus in the most interesting part: the releases.
The updates on the branched release are divided into pre beta, beta to pre release, pre release and release. Although the updates policy helps to have a more solid release, the updates after the release are a very important part of the user experience (for example, it’s an excellent way to polish the rough edges of the release).
Basically the policy says that the updates after the release must be primary bugfixes, so any updated package must avoid major releases with new features because that can introduce new bugs or instabilities. Moreover a release doesn’t need to track upstream changes to provide latest versions of the packages, because there’s a development branch (rawhide) to do that.
I would clarify the part of the major version number referring to a new release that introduces new features, because the version numbering in OSS isn’t that uniform (for example, in Cherokee every 1.0.X release may introduce new features), but since the rest of the philosophy section it’s well explained, it’s not a big deal.
The part that worries me most it’s the one that says:
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.
That’s unlikely to happen, because in the same way the distributions doesn’t have resources to backport fixes, upstream can’t support all distributors providing backports to the stable releases that are being packaged and distributed (btw, this could be an interesting role in every upstream project).
So we may end at the same position Ubuntu it’s running for some time: there are bugs that won’t be fixed until next release, because there aren’t resources to backport the fixes and it’s too risky pushing an update with new features (that would include a fix).
Of course I’m not talking about security issues of critical bugs, but it’s somewhat frustrating when it’s something that makes a productivity application crash or misbehave, and you know that problem it’s going to be there for six months until next release (and certainly there’s a chance to have new of those never fixed bugs in the next release). So updates stop working as a tool to polish rough edges in a release (and I don’t know if this is related to the worst release ever meme), and that’s bad.
In fact, that’s one of the best features of Fedora when I moved from Ubuntu because of my frustration with broken Pulseaudio deployments release after release.
Currently I’m running Fedora 12 and I’m very happy with it, and I’m not planning to upgrade until its EOL arrives. I wonder if that will be posible with the new updates policy. What do you think?
