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 Sat, 2012-11-03 at 00:44 +0100, drago01 wrote:

> > The number of variables involved in one is astronomical. Note
> > that neither Red Hat nor Microsoft actually support major version
> > upgrades for their operating systems,
> 
> Microsoft does. They do even sell upgrade boxes ...

Well, it's a bit complicated. They didn't support 'true' upgrades from
XP to Win 7, for instance - the 'upgrade' process just did a fresh
install and then tried to copy back 'important' stuff like your desktop
layout. And if it goes wrong...well you can call tech support and
they'll do their best, but you're not getting a refund. And Windows
upgrades *do* go wrong. Corporate deployments of Windows, to my
knowledge, virtually never rely on the upgrade functionality.

> > much lower levels of churn,
> 
> No they actually have way higher levels of churn ... just think about
> it ... in fedora we are talking about 6 months worth of chrun not 5+
> years. Can't speak for Red Hat but maybe this is one of the reasons
> why they don't support upgrades.

True, that was a bad point; the average rate of churn is lower but the
churn between any two releases is big.

> > (Also note how much trouble phone companies have
> > updating Android.)
> 
> That has more to do with how bad forking is for maintenance ... we
> don't really have this problem in fedora (ubuntu is driving themselves
> into this corner but that's OT).
> 
> > I also know what we do to test upgrades before we sign off on a release,
> > which is 'do a clean install of F-N in a VM and check it can be upgraded
> > to F-N+1'. If that passes, we ship. That is not a level of testing which
> > allows me to declare with confidence that our upgrade process is solid
> > and reliable ;)
> 
> Well it means that the process works. Everything else are bugs in the
> packages itself which you would have hit during a normal yum update
> otherwise.

That's an oversimplification. A stock install only has a small part of
our *official* package set installed. Any given user's system might have
any of the others installed, or any third party repo (including a
graphics driver from a third party repo). On some upgrades we reinstall
the bootloader or do other disruptive things. And again, I'm not saying
we could do upgrades better; the fact that 'it'd be just as bad with
yum' is besides the point. My point is that major version upgrades are
such an intrinsically unreliable operation that any workflow which
requires people to do one once a year has problems. They're not
something you can realistically expect people to rely on.

Microsoft don't really expect you to upgrade Windows. They expect you to
buy a computer with Windows X on it, use it for three years, then throw
it away and buy a new computer with Windows Y on it. Red Hat expects
something similar for RHEL - they don't expect people to upgrade systems
from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS
migrations, which usually involve buying new hardware, not upgrading
existing systems. This is an implicit acknowledgment that upgrades are
just not a great way to do things. I don't think we can realistically
expect Fedora to do it massively better. If you're going to do stable
releases of your operating system, it just doesn't make a lot of sense
to make people upgrade every twelve months. If you're going to have
stable releases, you should maintain them long enough that people don't
really rely on the upgrade function. That seems to be how the big boys
do it. If we can't do that, are the stable releases really achieving
much?

> > In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then
> > a week later they deal with bar-1.0 to bar-2.0, then a week later they
> > deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model,
> > everyone gets to deal with foo, bar, monkeys and five hundred other
> > changes all at once. Which is chaos on a stick.
> 
> But then you have to deal with this kind of stuff every time you
> update something. That's not really usable if you want to get work
> done.
> While the bigger upgrade leaves only hits you once or twice a year.

My position is that the people who use Fedora and the kind of people we
really _want_ to use Fedora can cope with it. Remember, I'm not
proposing it be as bad as Rawhide; we have the whole Bodhi karma process
to work with. I think it's plausible to design a process where people
only rarely have trouble with updates, even ones that are theoretically
pretty messy; about the same frequency they'd have had trouble with
upgrading our stable releases. Remember, I mentioned the kernel team as
a model; despite my sound gripe, they seem to be managing pretty well in
bumping older releases to newer kernels without causing massive
breakage. They do cause some problems...but we get 'some problems'
anyway.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net