Rolling release Fedora - "testing-release"-Proposal

Kevin Kofler kevin.kofler at chello.at
Tue Jan 31 10:55:10 UTC 2012


Matthias Runge wrote:
> You're right, putting a testing line between rawhide and stable makes
> software in stable a little older. Nobody said, packages in testing
> should stay there as long as in debian-testing.

Any time wasted by going through the extra testing branch is too much time.

And the extra transition wouldn't be the testing→stable one, but the 
Rawhide→testing one (because testing would be what stable would be branched 
from under your proposal). So the time wasted is the one it takes to go from 
Rawhide to testing.

> Let users decide, if something goes from rawhide to testing; take a
> limit of 3 days to stay in rawhide, before it's allowed for testing.
> Three days should prevent major breakages.
> 
> I know, this is kind of strict and burdens more work to maintainers.
> Building in this model into bodhi could automate almost everything of it.

Bodhi is a major PITA to work with. It just doesn't scale for the kind of 
development we do in Rawhide. The goal of Rawhide is to do DEVELOPMENT for 
the next release, NOT to ship a working rolling release.


If you want a rolling branch:
* The branch should be treated like an additional release, branched from 
Rawhide independently from the releases. Releases should keep being branched 
directly from Rawhide.
* Most importantly, the onus of maintaining the extra branch should sit 
ENTIRELY WITH THE PEOPLE WHO WANT IT! It is totally unacceptable to force 
all of us maintainers to support the additional branch we consider entirely 
pointless and unsupportable. (And I have explained many times why I consider 
a rolling release unsupportable, and several other maintainers agreed with 
me, read the mailing list archives.)
* IMHO, it should be required to use a name distinct from "Fedora", to make 
it clear that it is maintained by different people.
Maybe you want to work with the Fuduntu folks, who are basically doing all 
of the above. Forcing it on Fedora proper is not going to work.


> If we take your model (if I remember right): everybody is allowed to
> submit everything in every branch may lead to some instable systems.

That oversimplifying means you're attacking a strawman.

I don't want to allow any and all updates in a stable branch! Updates to 
incompatible new versions, where "incompatible" can mean any of:
* breaks dependencies (e.g. because it breaks a library ABI without 
including rebuilds of all dependent packages in the same grouped update),
* introduces known regressions (i.e. new bugs, but only if we know about 
them, not if somebody just speculates about how some new feature MIGHT 
introduce regressions without any actual issue being known),
* removes features,
* cannot use or import existing user data (documents, savegames, 
configuration files etc.),
* has a radically different user interface (e.g. GNOME 2 → 3, I'm not 
talking about a menu entry getting moved from one place to another here) and 
no option(s) to get the old interface (or something reasonably close to it) 
back,
* probably some other conditions I forgot (use common sense!)
should NOT be pushed. Yes, I think ultimately the call needs to be the 
maintainer's (having FESCo vote over every individual case doesn't scale if 
we want to encourage rather than discourage version upgrades), but that 
doesn't mean the maintainer should push "everything".

What I think that OTOH we *should* allow (whereas the current policy 
discourages it) in stable updates includes:
* new features (which should even be ENCOURAGED),
* library ABI breaks (as long as all dependent packages in Fedora are 
rebuilt and pushed in the same grouped update; and if packages in a popular 
3rd-party repository are affected, common courtesy dictates that you should 
also give them a heads-up and try to coordinate things with them, even 
though that is officially out of the scope of Fedora),
* minor/harmless user interface changes (a.k.a. upstream usability tweaks).

> This model can't prevent breakage in any branch. I'd say: it provokes
> breakage. I'm pretty convinced, nobody wants to break something.

Actually, I strongly believe the model will not introduce breakage where 
followed properly. (In fact, it had been unwritten policy for large parts of 
Fedora before the new update policies and worked really well.)

What my proposed model WOULD achieve is that you would get almost all the 
new software you'd get in a rolling release, but NOT where it breaks things. 
As a result:
* The users of stable releases would get no more breakage than now.
* You would end up with LESS breakage than by using a rolling release.

> Ignorance, even through no ones fault will do easily harm here.

Ignorance must be fought through education, not bureaucracy!

        Kevin Kofler



More information about the devel mailing list