Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

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