On Fri, 2012-11-02 at 11:55 +0100, 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.
<snip>
Honestly, my take on this is that anything like Debian's system would be
over-engineering.
The reason I like rolling release for Fedora is that Fedora is supposed
to be where we do cutting-edge development and integration. The way I
read Fedora's mission statement, target user statement etc is that it's
not _really_ meant to be a 'stable distribution' at all. We do a fairly
poor imitation of being one, to no great effect, but wasting a great
deal of resources.
The entire QA team (and the entire anaconda team, for that matter) is
currently spending virtually all its time trying to help bash the new
anaconda into something vaguely resembling shape for a fairly arbitrary
release deadline, so we can ship something called 'the Fedora 18 stable
release' without *completely* corpsing Jimmy Fallon-style as we do the
release announcement ("suuuure, this is a stable release..." *giggle*
*giggle* *guffaw* *full-blown laughing fit*). We've barely looked at the
desktop or the update mechanism or anything else. Stuff in Fedora
regresses all over the place...there all sorts of weirdness in how
fairly basic bits of our OS work, like updates and login and various
other crap. We can't really look in a mirror and say that, say, Fedora
17 is a serious stable operating system release by any reasonable
definition. It's a stable Fedora release, and we all know what that is.
We had a feature for a smooth boot process back in F12, remember? where
everything was polished and had the same background and you didn't see
any mode transitions? How's that working these days? It was supposed to
be a feature of our operating system. We almost got it done for one
release, and have been consistently regressing it ever since. That's not
what stable, mature operating systems do.
Over in kernel land, for a long time, the kernel team was wasting tons
of resources maintaining three or four different kernels for three or
four different releases - which is what they're supposed to do, under
our current policies. They have now solved that problem, but only
essentially by moving the kernel to a rolling release model: F16, F17
and F18 now have more or less the same kernel build, and F16 is like
three major versions on from where it started. Let's be honest - this is
a clear breach of what our update policy is supposed to achieve. We
wrote a get-out clause into the update policy to let the kernel team do
this and claim they're in line with the policy, but that was an obvious
process hack.
Basically what I'd like Fedora to do is 'that, only bigger'. We are not
really doing a convincing job of releasing and maintaining stable
operating systems, we're just wasting a lot of resources on pretending
to do so. Badly. Resources we could better be spending on what we're
good at - constantly building and iterating interesting new stuff in the
broad framework of a distribution that's usable enough for the job of
building and testing interesting new stuff.
If we want to look at the Debian model, I'd say we should have 'sid' and
'testing' or even just 'experimental' and 'sid' and stop lying to people
that we are even interested in, let alone that our release cycle and
processes are capable of, building a stable general purpose operating
system. That's not what we're doing in practice, it's not really what
we're _trying_ to do, and that's fine. We are constantly building a
rough prototype of the next generation stable general purpose operating
system, and I think that's both a necessary thing that no-one else is
really doing, and a really fun thing to be doing. But we need to be
honest about it.
A light rolling-release model matches what Fedora is really doing rather
well, to my mind. It lets us iterate quickly, with an appropriate level
of QA that isn't needlessly stifling to development. In theory we'd be
'lowering our standards', but in practice they're lofty words we're not
backing up anyway. On a personal level, I can say for sure it'd free up
a lot of QA resources that are currently more or less wasted on an
almost constant treadmill of installer testing in order to be 'ready for
release' every six months. We could move to simply building, testing and
shipping updated installer images _when it made sense to do so_, not
'every six months because we do a release every six months'.
A heavy (three-tier, with a 'stable' tier) rolling-release model by
contrast would just wind up tying up needless development and QA
resources trying to ensure stability in the 'stable' tier, which I
rather suspect we'd wind up doing a bad job of anyway, because again,
stability really isn't what Fedora is about.
Anyway, we've rather torpedo'ed the feature process discussion now, and
I'm sorry about that :/. Hence the topic change. But while we're blue
sky thinking about massive release process changes, I think it's worth
keeping a firm grasp on what Fedora is really about and what it's
capable of achieving.
(the above is of course my personal opinion, and nothing official from
RH. in fact, I've no idea whether such a plan would be better for RH or
worse...my angle on this is purely a Fedora-based one.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
