LTS and release methodology

[Krzysztof Lichota]

2008/7/9 Matt Zimmerman <mdz at ubuntu.com>:
> On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote:
>> 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.

Yes, some do not allow parallel versions, but many do.
But at least they allow installing different versions without hassle.
Linux users must jump through the hoops if they need OpenOffice 2.4 on
Dapper which has 2.0.

The argument about ISV doing their packaging in this way is void (at
least for FOSS software) as in Ubuntu, Ubuntu packagers are doing
packaging, not ISVs.

It is not a question how it is done, but that it is possible (and
easy) to install various versions of apps. To the point that it is
easier to explain user how to run Firefox 3 through Wine on Dapper
than to explain him how to get it running on Ubuntu itself.

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

Well, IMO in most cases this would require just creation of
appropriate packaging process and appropriate build tools. Build
systems already support installing to different directory prefixes,
with prefixes/suffixes to binary names, etc.

And I don't think this would require linear time. It would be one-time
job to convert it and then the maintenance would be the same. So the
tradeoff would be to make current version "mediocre". But to really
tell it, we would have to start an experiment and try it.

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

If you install OpenOffice from Hardy, you cannot keep the one from
Dapper. And I really don't think the one from Dapper would work on
Hardy.

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

Maybe this version in newer LTS should get "limited transition
support" which ends when the support for  older LTS ends. This way
security fixes from older LTS would be simply forward-ported to newer
LTS. No additional security-related effort would be needed.

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

In many corporations there are different versions for example of Word.
To get to know which version of application it is you just have to ask
user to go to Help->About.
You must anyway ask which version of _Ubuntu_ user is using. And I
think it is even harder to get this information, it is not in any way
obvious to user.

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

You must maintain security fixes for newer packages anyway in newer
versions of Ubuntu. You backport package from newer version together
with security fixes. I am doing this all the time - yesterday I have
backported Firefox 2.0.0.15 to my Firefox 2 repository
(http://ola-os.com/addons/pool/dapper/firefox2/ ).

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

The default depends on company/person policy. If you run an
application, for example click on OpenDocument file, you should have a
choice of opening it in "OpenOffice" (policy default), "OpenOffice
2.3" and "OpenOffice 2.4".

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

This is what IT departments define. Users would mostly use
"OpenOffice" (the default set by IT department) unless support/power
users would tell them to use other version.

In case of home users I think the default should be the newest version
(as it is currently in Ubuntu). But the user would have a choice of
running "OpenOffice 2.3" by clicking "Open with" if he wishes so.

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

Yes, making all the choices for users has no chance of getting it
right. That's why users must have the way to make their choices to
suit their needs. If you are creating distribution version A with one
fixed  set of packages and version B with another set of packages you
will always have users which cannot use A nor B, because A does not
contain OpenOffice 2.4 and in B VGA-out does not work in your laptop
[1] (substitute OpenOffice/VGA-out with your favourite app/feature -
music player, web browser, etc.). The only way to make them happy is
to backport app from B to A or forward-port from A to B.

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

Alternatives are for administrators. They should constitute what I
earlier called "policy default", i.e. what you run when you choose
"OpenOffice" not "OpenOffice 2.3" or "OpenOffice 2.4". Or when you
just double-click a file.

For users, there is "Open with..." context menu in their desktop environment.

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

"Open with" is discoverable.

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

Yes, but it is "all or nothing". I cannot cherry-pick what I want. And
I really do not understand why it was done this way as the tools to do
it separate are already there.

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

I am running the experiment all the time and it works pretty well,
that's why I am surprised it is not done this way in Ubuntu backports.
I am running the repository above and it contains one component for
each application. You can install for example only Firefox 2 by adding
the following line to /etc/apt/sources.list:
deb http://ola-os.com/addons dapper firefox2
And when you choose to install Firefox 2 this way, you do not have to
upgrade "dcraw", just because it happens to be also a backport in my
repository.

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

Yeah, the ultimate argument :) Let's say they are welcome to take
packages from my repository and put it in dapper-backports. It is open
source after all ;) Of course they need some cleanup, I am rather
mediocre packager. But I think it would be rather hard from Ubuntu
policy point of view. If you put Firefox 2 in -backports, the users
which enabled backports to get Amarok 1.4 might not be happy to get
Firefox 2 by the way.

[1] This is just a made up example inspired by latest discussion about
VGA-out support being worse and worse in latest versions (due to X.org
changes). The real-world example would be that on my laptop in Dapper
my video card (Intel X3100/GMA965) is not supported, and in Hardy
"Delete" key on the keyboard does not work. So I... backported X.org
intel driver to Dapper.

-- 

	Krzysztof Lichota