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)))

[Simo Sorce]

On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:
> On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote:
> > On Fri, 02 Nov 2012 15:17:02 -0700
> > Adam Williamson <awilliam at redhat.com> wrote:
> > 
> > ..snip...
> > 
> > > If you're using a Fedora release today you're _already_ fighting OS
> > > bugs more often than most people do, I'd say. I disagree with drago's
> > > assertion that my description was of people who use Rawhide. It was
> > > not intended to be, and it was drawn from the experience of me and
> > > other people who do not run Rawhide. I almost never run Rawhide, only
> > > Branched.
> > 
> > Perhaps you have your head too much in the Branched world right now?
> 
> Not really. I think I have my head more in the 'real' world than some
> Fedora folks do though ;)
> 
> I usually run Branched on my desktop and current stable (F-N) on my
> laptop. How stable is that? Well, the sound on my laptop broke with F17.
> For several months. It only got fixed because I took the bug upstream
> and then ensured the fix got ported down into Fedora...that's the
> experience that *someone who knows how to get people to fix his bugs*
> has with our product. Imagine the experience a normal person has.

Some time it is a bit painful, but on average it's ok, I've seen the
same kind of issues on any OS, imagine how nice it is to report a bug
like that to Microsoft or Apple ... in most cases you get back a: ask
your sound cared/laptop retailer ... and they will blame their OEM
and  ... if you are lucky they already solved it otherwise tough luck.

> Sure, like I said in another mail, we've got better at that than before.
> But as I also said in the same mail, you still have to do a version
> upgrade every twelve months. That alone is ridiculous for a 'stable'
> operating system.
> 
> I don't think we destabilize things - in the sense of 'you update and
> your machine stops working' very often within a single one of our stable
> releases. That isn't my point, really. My points are more:

I think you are confusing stable with LTS.

Stable means upgrade won't break what works, it doesn't mean that we
will fix all the known bugs and it also doesn't mean we maintain it
forever.
It does mean that it would be nice if upgrades were relatively smooth
and just plain possible.
And if you use a rolling developer model where upgrades *must* be
graceful, then you should get that for free, however you will need to do
a little bit more work to put stuff in development, just dumping the
latest upstream master tree snapshot and hoping it works won't cut it.
At the very least you need to do a smoke test upgrading from the
previous one.

> * Upgrading every year, with an unreliable upgrade process, is not
> something you have to do with a proper stable OS

On some stable OSs you cannot upgrade *at all*. It is true that some OSs
are maintained for longer time. A short release cycle puts a lot more
emphasis on working updates, but to be honest I haven't had huge issues
with Fedora, no more than I used to with debian/ubuntu
There are some cases were it went south on some releases and I had to
manually handle it. But then if that's a problem we could simply create
a /home partition by default and users can choose to reinstall just the
OS and keep the /home intact.
For a desktop that should be ok in all cases where you fear an upgrade
would be too dangerous.

> * We do not insist on a level of polish or lack of functional regression
> in our stable releases which is any way consistent with a true
> productized general purpose OS

Maybe if we cut stable releases to 1 we can improve this ?

The only real reason we maintain N-2 is that forcing a 6mo update on
everyone is just ridiculous, but a 1y cycle seems reasonable enough, and
with a rolling devel release there would be less reason for frequent
stable releases.

> I'm as well placed as anyone to know _exactly_ what we as a project are
> happy with signing off on as a final release, and based on my experience
> working on, using, and doing user support for various distributions and
> operating systems, I'm happy to maintain that that level is nowhere near
> a level suitable for a general-purpose stable OS. Our standard for a
> final release is, broadly, that the installer works pretty well, there
> are no giant booboos on the desktop, and you can run the updater. We
> don't care if a feature that was introduced in the previous release is
> completely broken, unless it affects the critical path, we just say 'fix
> it with an update'. We don't hold releases for cosmetic bugs, even
> really obvious ones. We don't hold releases for usability issues. These
> are all things that serious grown-up operating systems do.

I think this is ok, and also the reason why most people wait a month
after GA, it is usually fixed by then because *finally* developers moved
on the new "stable" release, discovered all the bigger issues, and fixed
them. It means that stable isn't really stable enough for less technical
users until 1mo after release but that is ok IMO.

> That's fine. My posts have a general negative tone just based on the way
> I'm constructing my argument, but it's important to realize I don't
> think this is a _problem_. I think what we achieve is roughly what many
> people who run Fedora want. But we _only_ achieve that level, and we
> really don't need this unwieldy system of maintaining four releases at a
> time to achieve it.

I agree I find the current scheme a bit silly too.

>  My fundamental argument is there's a bit of a
> disconnect between our release process - which is sort of aping the way
> a stable general-purpose OS would be released, but on fast-forward and
> with far fewer resources - and our actual goals for the project and the
> standards we really enforce. We don't _need_ the heavy, constant release
> cycle we currently employ in order to deliver the good things we already
> currently deliver.

+1 really

> Anyway, I think the point is mashed into the ground by now, so I'll
> stop. My proposal is more about trying to get people thinking at a
> fundamental level than it is necessarily something I actually expect the
> project to adopt wholesale - I just want to make the point that, in
> designing whatever changes we may make to our processes, we should keep
> a realistic view of what Fedora is actually _for_, and not over-engineer
> things.

I think you should push your vision forward instead, I am sure on board
reducing the number of releases and silly work, and having a better
development version that more people can really use.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York