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:18 +0100, drago01 wrote:
> On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson <awilliam at redhat.com> wrote:
> > [...]
> > * Upgrading every year, with an unreliable upgrade process, is not
> > something you have to do with a proper stable OS
> 
> I am not sure why you call it unreliable ... I *never* reinstall

Because I read the forums =)

It's not usually terribly unreliable for me either. But I'm a smart
cookie like you. I update my systems with yum and I know what I have to
do to make it work properly - I follow the instructions and I know how
to wiggle my way around dependency issues. This is second nature to me
as I'm sure it is to you. You've probably dealt with bugs on upgrades
before that you've forgotten about, even. Also, I don't use third party
repositories. Normal people do. Especially with a distro like Fedora
which doesn't ship Flash, proprietary drivers, Chrome...

I've been hanging around user forums for Mandriva, Fedora and Ubuntu for
a decade now and I can tell you, every time a new release of any of
those comes out, the forums get a big dump of people with problems
upgrading. Regular as clockwork. has always happened, more or less will
always happen. operating system upgrades are an insoluble problem,
really. 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, both of which have exponentially
more testing done on them, much lower levels of churn, and much smaller
sets of packages. (Also note how much trouble phone companies have
updating Android.)

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

> unless I really had to (moving one installation from i386 to x86_64).
> Otherwise I always upgrade using either anaconda back in the days and
> then preupgrade.
> 
> There is some weird attitude that "upgrades don't work anyway people
> should just reinstall". Not only is a reinstall a lot more work it is
> just not something you could ask from a user to do every 6-12 months.
> 
> Technically there is no difference between an upgrade and package
> updates just the package set is larger, it just makes dealing with
> stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
> the whole system it will regardless whether you upgrade from FN-1 to
> FN or doing a "yum update" in a rolling release.

Well, kinda. The advantage of a rolling release is that it tends to
narrow the focus. You don't have a million people hitting five hundred
potentially destabilizing updates all at once; you have a million people
all getting one potentially destabilizing update at a time (or, at
least, a fairly small set at a time). When everyone starts yelling, you
can just look at what got updated the night before and probably find the
culprit. That's what happens with Rawhide, after all. And anyway, I
don't think a rolling release would be *better* from this point of view
- as with my other points, I think a rolling release would allow us to
do *just as well* while reducing our testing and development overheads.

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