LTS and release methodology

[Krzysztof Lichota]

2008/7/8 Matt Zimmerman <mdz at ubuntu.com>:
> On Tue, Jul 08, 2008 at 10:38:01AM +0200, Krzysztof Lichota wrote:
>> I can't agree here. IMO bugs which people already know, they got used
>> to and found workarounds for, are less damaging for system reputation
>> than bugs which are unexpected.
>
> I don't think we're arguing the same point here.  I agree that known bugs
> are often preferable to unknown bugs, and this is why Ubuntu releases have
> overlapping maintenance cycles.  For folks who want old, predictable,
> well-known behavior (even though it has some bugs which may have been fixed
> in subsequent releases), Ubuntu 6.06 LTS (desktop) will be maintained for
> another year.

I am talking only about LTS releases and overlapping of their
functionality, as well as maintenance cycles.

>> But the answer is pretty simple: do not choose. Ship both versions and
>> let users choose which version to use. Preferably make application
>> possible to live side-by-side, i.e. version 2.3 and 2.4 can coexist at
>> the same time.
>
> 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.
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.

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.

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

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

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

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

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

Or one can use desktop environment alternation, i.e. using .desktop
files or MIME database.
I am not sure which mechanism would work best, maybe combination of those.

>> Additionally, ship _newer_ versions of important apps to LTS releases,
>> so that continuity is kept. If LTSx release contains OpenOffice 2.2
>> and new version 2.3 appears, port it to LTSx, so that when version
>> LTSx+1 appears with version 2.3 and 2.4, they will be able to
>> transition smoothly by using version 2.3 (assuming it works for them).
>
> 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.
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/ ).
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.

Regards
-- 

	Krzysztof Lichota