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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
