LTS and release methodology

[Matt Zimmerman]

On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote:
> 2008/7/8 Matt Zimmerman <mdz at ubuntu.com>:
> >> [package multiple versions of everything]
> >
> > This sounds simple enough, but the implementation gets complex very quickly,
> > as does future maintenance and support.
> 
> It is a lot of effort, but if we want to compete with Windows, which
> makes it possible (and easy), it should be done.

As far as I'm aware, Windows provides no tools or infrastructure to make
this easier.  It is completely up to the ISV how their software is
installed, and many of them detect an existing installation and upgrade it
rather than install in parallel.  Every application does it differently.

> And as it _is_ significant effort, I think it should be done only for
> key applications of desktop environment: for example office suites,
> browsers, audio/video players.
> 
> BTW. It is already done for example for PostgreSQL - Dapper has
> packages for PostgreSQL 7.4, 8.0 and 8.1. They can coexist and run
> along each other. User chooses which package to install and then which
> versions to run.
> 
> I know Postgres is not desktop package, but it shows it is possible to do.

No one would argue that it is impossible, but with the current tools, it is
done at a linear increase in developer effort.  Ubuntu developers can much
more effectively spend their limited time making one version very good than
making two versions mediocre.

> The problem is that Dapper ships PostgreSQL 7.4, 8.0 and 8.1 while Hardy,
> next LTS release ships 8.2 and 8.3. So there is no way for smooth
> transition from Dapper to Hardy by upgrading database for example to 8.1,
> switching to Hardy and upgrading further. This is the "functionality
> overlap" I was talking about.

It is generally possible to keep obsolete packages installed after an
upgrade, so there's no forced upgrade here.  However, the packages from 6.06
won't receive maintenance updates on 8.04.

Providing 10 years of support for an old version of PostgreSQL to support
this use case would not be a wise choice.

> >  "Which version of Ubuntu are you running?" suddenly isn't as useful to
> >  the person on the other end of the phone trying to help you,
> 
> I don't think it is a big deal. You can ask what version of application
> person is running. Helpdesks all around the world do it all the time.

They do, and it works reasonably well because the user generally only has
one version of the application.

> > and the question "do I have the necessary security updates installed?"
> > no longer has a simple answer.
> 
> Why not? If someone has necessary repositories installed, the answer
> is very simple. Provided that security fixes go to the same repository
> as application which is installed.

You miss my point.  Implicit in your proposal is a need for twice as many
security updates.  Where do you think these updates would come from?  They
do not fall from the sky.  

> > Which version of OpenOffice should launch when you click on a document
> > in Firefox?
> 
> The default.

The default version should be the default?  Simple enough. :-)

> If only one OpenOffice version is installed, there is no problem. If two,
> I think it would default to older (or installed last).

Which one?  The older, or the installed last?  Which one does the user
consider their preferred version?  Which one works best for their purposes?

The answer doesn't matter.  The point is that this is another choice which
needs to be made on the user's behalf, and with each new choice, there is
less chance of getting it right.

> There is already system for handling that - /etc/alternatives/.  According
> to my Dapper installation it already contains 240 commands with
> alternatives.

I am familiar with it.  You'll find that about half of those are man pages,
not commands.  But do you know how users can discover, in the desktop, what
those settings are and change them?  You can't.

Adding a new, opaque, non-discoverable, counter-intuitive dimension to every
important desktop application doesn't sound like the right approach to me.

> > The backports repositories attempt to provide this kind of experience, and
> > also demonstrates some of the shortcomings of this approach.
> 
> What shortcomings are you talking about?
>
> The ones I am aware of:
> 1. Backports do not provide packages which can be run alongside
> others. It is just newer versions of apps, which replace older ones.
> This is sometimes OK, but for example for OpenOffice or Firefox, it
> would be better to have two versions alongside.

It provides the user with a choice of "old, stable and officially supported"
or "new".  The tools do not provide a great deal of flexibility for
this case, but the choice is there.

> 2. Backports are one big bag with newer applications. If someone wants
> to install only one app, he gets upgrades for others. IMO this is very
> serious design flaw. The solution would be to create separate
> repositories for apps (like PPAs) - repository for Firefox 2, for
> Firefox 3, OpenOffice 2.3, OpenOffice 2.4 and security fixes would go
> to this repository, not to some external "security" repository.
> Of course it is sometimes not possible or very hard to do due to
> dependencies (for example Firefox 3 requires newer version of gtk than
> in Dapper) but in many cases it is as easy as updating build
> instructions (I have done that for a few packages, including Firefox
> 2, Amarok 1.4.8 and even linux-image-2.6.22 backported to Dapper, see
> http://ola-os.com/addons/pool/dapper/ ).

One of the nice features of PPAs is that anyone can set one up very easily
and start using it.  So if you would like to run an experiment and see how
well this works, you can try it.

> 3. Backports contain very limited set of apps which really undermines
> its feasibility. Examples for Dapper
> (http://packages.ubuntu.com/dapper-backports/allpackages): no newer
> version of Firefox, no newer version of OpenOffice, Amarok 1.4.3
> (while 1.4.8 is available), etc.

If you're interested in seeing more backports, you can join the team and
contribute them.

-- 
 - mdz