On 11/02/2012 10:55 AM, Stanislav Ochotnicky wrote:
Quoting Michael Cronenworth (2012-11-01 18:33:24)
Adam Williamson wrote:
I didn't want to throw this grenade into the debate, but now someone
else has, I'll just note that I was in favour of this before and I'm
still in favour of it now. :) Rolling release is a model that makes
clear sense for a distribution with the goals that Fedora has.
I've wanted to write up a blog post about my plan for a rolling release,
but I'll post a snip-it here.
Fedora Rawhide - stays as is... it is a rolling release
Fedora Feature - think of it as F18 beta right now
Fedora Stable - think of it as F16/F17 right now
People choose the branch level at install time. Of course, like now,
people can override this in the future with a change of fedora-release
or yum --releasever. However, per-package updates from another branch
level might not be something everyone can agree on how to handle, so it
might be wise to limit support of it at first.
Workflow:
A shiny new feature is introduced in Rawhide. Things go boom. Not many
people are hurt by this. Once it has been given a few band-aids the
feature could be submitted to Fedora Feature. After some hardening and
polishing the feature could finally be pushed to Fedora Stable.
I feel this should give a good compromise to everyone's fears of a
rolling release. It gives the feature freaks a place in Fedora. It gives
the stable stubborns a place in Fedora.
I'll wake up from my dream now.
I recently came up with similar 3-layer idea. My description was a bit
different, something like this:
1. level - rawhide-like repository, more or less anything goes
2. level - package moves here after maintainer says "this package has been
working for me for some time and looks OK. Let's integrate properly
with rest of the system".
3. level - packages integrated and experience should be splendid :-)
However let's see how we'd handle systemd change with this system:
1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd
as worthy FEATURE for future stable (3rd level). Packages interacting
with init system can take their time updating.
2. level - systemd moves here. After this point, packages moving from 1st level
here, will have to support systemd. Experience will likely be shaky
for a time, then settle down.
3. level - after some time (1 year, 2 years?) systemd moves here and all
packages that have been fixed to work with it as well
There are several problems with this approach though:
1. There are always multiple big changes happening in fedora. So even stable
would see big updates on relatively frequent basis.
2. Several big changes will interact with each other. I.e. Gnome update will
contain some daemons so they'd have to integrate with systemd on 2nd level.
But then Gnome couldn't go into 3rd level before systemd.
3...x. a long list of further problems
I am hopeful that we could make this work. Would anyone be willing to do
analysis like this for multiple updates and play devil's advocate as well?
Ideally trying to see how we could create processes to handle updates of the
last 1-2 years? Because all I could come up with is: we'd end up like Debian,
where stable is...ancient. Not that that is bad in itself if you can pick.
Trust me when I say this we have to fix other processes we have *before*
we can properly fix the feature process.
Until that is done there is no point in trying to fix the feature process.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
