Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)

[Kevin Kofler]

Jon Masters wrote:

> On Sat, 2010-03-13 at 01:09 +0100, Kevin Kofler wrote:
>> Jesse Keating wrote:
>> > Then in my opinion those users, and those maintainers who wish to cater
>> > to those users, can go start their own project.
>> 
>> Even if those users are 70+% of the current Fedora users?
> 
> Prove it. And prove your point that users are desperate for intrusive
> rolling updates and won't just use Rawhide instead if they want to get
> the very latest and greatest unbaked stuff.

Some evidence pointing towards that has been provided. Even if you do not 
trust the evidence, you cannot disprove it either. Is losing 70+% of our 
users really a risk you're willing to take?

> And while you're at it, why not tell us why people who want to update
> constantly aren't just running Gentoo or some other compile from source
> distribution?

Because compiling from source takes a lot of time and CPU cycles for no 
practical benefit. And also because source-based distributions are 
inherently less reliable (all FTBFS bugs are fatal, people can end up with 
vastly different binary builds depending on what they had in their 
buildroot, dependency tracking is more complex and thus has more chances to 
screw up etc.). And finally, Gentoo isn't even that bleeding edge anymore. 
Fedora currently often gets a new KDE into stable before Gentoo does. (Yet, 
Gentoo suffers from the same kind of "rolling release" diseases Rawhide 
suffers from. Even using only packages marked stable doesn't save you from 
disruptive transitions, it just delays them.)

> Six months is a blink of an eye compared with many things in life. Many
> Fedora users don't even update to every release - some only once a year
> or perhaps even less.

But at least for some, that's only made possible by our application 
upgrades!

> What's the point in a tested, QA'd release if you can unilaterally decide
> to push an update that invalidates all the testing?

The update also gets testing.

For example, KDE 4.4.0 got through several stages of testing: Rawhide and 
kde-redhat unstable (starting with early prereleases, up to the 4.4.0 
release, so this brought months of testing; kde-redhat unstable had rebuilds 
of the Rawhide packages for F11 and F12), then updates-testing and kde-
redhat testing (kde-redhat testing mirrored the packages from updates-
testing for those who wanted to test only KDE and not all the other stuff in 
updates-testing). We only pushed it to stable once we were confident that 
there were no remaining blockers.

While I think direct stable pushes make a lot sense in some cases (as 
discussed in another thread), I DO NOT suggest that such feature upgrades be 
pushed directly to stable!

        Kevin Kofler