EOL of Warty?

[Colin Watson]

On Thu, Mar 23, 2006 at 10:47:48PM +0200, Alan McKinnon wrote:
> On Thursday 23 March 2006 20:10, Colin Watson wrote:
> > On Thu, Mar 23, 2006 at 06:36:05PM +0100, Dennis Kaarsemaker wrote:
> > > On do, 2006-03-23 at 16:20 +0200, Alan McKinnon wrote:
> > > > It's not unreasonable for the release team to expect you to do
> > > > an update every six months.
> > >
> > > I think that that is unreasonable,
> >
> > I agree. If we expected everyone to upgrade every six months, we
> > wouldn't support releases for eighteen months.
> >
> > > however: it is clearly stated that upgrades skipping a release
> > > are not supported[*] so you could have known in advance that when
> > > you decide to upgrade, you need to do it in steps.
> >
> > This will be in the Warty EOL announcement, to remind people.
> 
> But I used to word "update", you are talking about "upgrades". Like a 
> typical pedantic engineer, I see a difference.

Even after reading your post, I'm not really all that sure of the
difference. :-) The nearest precise definitions of those terms are
apt's, where "update" means "update the package indices" and upgrade
means "fetch and install new packages". An update every six months in
these terms is not terribly useful, so I assumed you must simply mean
"fetch and install new packages", which I call "upgrade".

Is the distinction you're drawing one between applying security updates
and upgrading to the next release?

> The GGP mentioned infrequent updates on his wife's machine, I
> responded that it's not unreasonable to expect him to do updates
> maximally six months apart, so that doing an upgrade (if he wants to)
> to the next OS is relatively easy.

I do still somewhat disagree here. While it's true that we expect and
hope for people to apply security updates reasonably frequently, we have
an awareness that in many environments it is not sensible to upgrade
from release to release every six months; for instance, installations in
schools would not want to upgrade in the middle of the school year, and
in office environments there will often be a long test and deployment
cycle. While the actual physical process of upgrading from release to
release isn't too much work, it may well take inexperienced users some
adjustment to cope with the changes on the desktop, and so I can quite
understand that even home users might well not want to go through a
mental gear-shift every six months.

> An engineering policy of not supporting upgrades over skipped releases 
> is totally sensible. Trying to do it would be near impossible - the 
> dev team can provide miracles, but the impossible is still a tad out 
> of our reach.

The mechanics actually aren't the hard bit; if you're being reasonably
diligent about some fairly well-understood packaging practices, then you
can support upgrades of Debian-style systems over practically indefinite
distances, although some manual steps may end up being required the
further out you go (i.e. you may have to stretch the definition of
"smooth upgrade" a little).

The problem is that we can't really guarantee that these practices are
applied to every single package, and "officially supporting" such
upgrades would involve a combinatorial explosion of testing before each
release. Unofficially, an experienced administrator can probably deal
with it anyway, but will have to cope with strange package relationships
that apt may not be able to resolve easily, conflicts in configuration
files, and probably more than the usual share of other bugs. It would be
interesting for somebody with lots of free time to experiment with this
and let us know how bad it is! Somebody tested this with upgrades of
very old Debian systems a while back, but I can't find the link at the
moment.

To be honest, the chief reason that upgrades from very old releases
don't work is that every so often a developer wonders why some bit of
compatibility cruft is there, realises it's to cope with something three
releases ago, and gets rid of it. :-)

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]