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

[drago01]

On Sat, Nov 3, 2012 at 12:32 AM, Adam Williamson <awilliam at redhat.com> wrote:
> 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.

What kind of problems? "I did upgrade and now my sound card does not
work?" or actually problems with the upgrade itself?
The former would just have happened with a reinstall as well.


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

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

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

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

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.