FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Kevin Kofler kevin.kofler at chello.at
Sun Feb 28 23:58:07 UTC 2010

Mike McGrath wrote:
> So when Fedora 12 came out, we allowed users 7 months to upgrade because
> the latest version of stuff is too unstable for them.  At the same time
> we're also forcing them to upgrade to the latest versions of those
> packages in F-11 anyway?  I hope you can at least acknowledge why I'm not
> following the logic here?

Those packages we're upgrading in F11 are not the ones which are causing 
their problems with F12. E.g. KDE 4.4 can't possibly be what prevented them 
from upgrading to F12 because F12 originally shipped with 4.3. And more in 
general, the idea is to push updates IF AND ONLY IF they don't break things, 
while leaving the disruptive changes to Rawhide / the next release only. 
(For example, we don't enable KMix PulseAudio integration by default because 
it makes KMix work significantly differently and some users would not like 
losing their hardware controls by default in an update. (That said, in this 
case, the feature can be enabled or disabled at runtime, so we ship it, just 
disabled by default, it can be enabled manually. That way, we provide the 
feature without disrupting anything.))

The point which you don't seem to understand is that there are 2 classes of 
upgrades (well, the line may not be perfectly clear-cut, but it's usually 
pretty well drawn):
1. upgrades which disrupt, regress or break things. Those can only be pushed 
to Rawhide, if at all. (Sometimes it might be better to not push a change 
even to Rawhide.)
2. upgrades which do none of the above. Those are what adds value to stable 
releases and pushing those is a good thing. It provides value which no other 
major distribution is providing, at least not those with numbered releases. 
(And completely rolling releases are not a solution because they have no 
good way to handle type 1 upgrades, that's also why Rawhide is not suitable 
for most users.)

        Kevin Kofler

More information about the devel mailing list