LTS and release methodology

[Krzysztof Lichota]

2008/7/7 Matt Zimmerman <mdz at ubuntu.com>:
> On Mon, Jul 07, 2008 at 10:43:44AM -0500, Luke L wrote:
>> --New software should not be included simply because it is new, quite the opposite: new software should rarely included. Firefox beta and OOo 2.4 are notable examples.
>
> I can't agree with you on this point.  In my experience with open source
> software, I have nearly always been better off with current software.
> Ubuntu was founded with the idea of delivering this to users.
>
> Newer software may introduce some new problems, and it may fix some.
> However, software which remains unchanged will never improve.

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.

Imagine an office user which works on an important office document for
his boss' meeting. He recently got his brand new LTS system.

Now, in scenario 1, he gets LTS system with old, but stable version of
OpenOffice 2.3 with known bug - let's say printing to PDF does not
work.  He will just not print to PDF but print directly or use some
other way to print to PDF, because he knows what to expect.

In scenario 2, he gets LTS system with new OpenOffice 2.4 which has
PDF printing fixed, but during the work on very important document, it
turns out that the it displays Arabic numbers instead of decimal
numbers.

Both of these bugs can be potentially damaging for system reputation
(user cannot perform office tasks), but the first one can be worked
around beforehand by IT department or other means. BTW. IMO it would
be useful to prepare such list of "corporate-important LTS bugs" so
that IT departments would be aware what problems they can expect.

My example is a little biased and someone can point out that version
2.3 might have critical bug which renders 2.3 useless for some group
of people, while 2.4 has this bug fixed. But it can be also the other
way round - 2.4 might have critical bug, which is not present in 2.3
(for other group of people). So the question which version to choose
seems hard.

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.

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

Just my 2c :)

-- 

	Krzysztof Lichota