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

[Adam Williamson]

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.

> In my experience, in the last few years, Fedora stable releases have
> become much more stable. My "stable" boxes here at home I have not
> really had to poke at since I upgraded them to Fedora 17. I apply
> updates every few days and things keep working along fine. 
> 
> In previous cycles there were some real nasty brown paper bag type
> blowups that required me to do things to downgrade or tweak to keep my
> stable version working, that (knock on wood) hasn't happened in f16/f17
> in my experence. 
> 
> I realize there are bugs and problems that hit, but I think the stable
> updates policy has helped keep those down. (Cue KevinK to come in and
> shout and tell me how wrong I am, etc etc)

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:

* Upgrading every year, with an unreliable upgrade process, is not
something you have to do with a proper stable OS
* 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

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.

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

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net