LTS and release methodology

[Matt Zimmerman]

On Thu, Jul 10, 2008 at 10:13:00AM +0200, Krzysztof Lichota wrote:
> 2008/7/9 Matt Zimmerman <mdz at ubuntu.com>:
> > 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.

It is possible (and easy) to install multiple versions of applications which
are packaged that way.  Few packages are, because it requires more effort
(both initially and ongoing) to do so.

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

Some build systems do, some don't.

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

Indeed.  If you believe that some one-time work will solve your problem, you
are in an ideal position to test this.

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

No, but you were talking about PostgreSQL, where you can.

> And I really don't think the one from Dapper would work on Hardy.

I would be surprised if it stopped working.

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

It is already more complex than we would like for users and administrators
to understand which packages on their system receive maintenance and
support, and which don't.  The idea of LTS is that one can deploy the system
and not think about it too much for a few years.  Adding "time bombs" where
certain applications start to reach end-of-life earlier than others would
complicate what is presently a simple cycle to understand.

> No additional security-related effort would be needed.

First of all, porting changes to different versions of a package is real
work.  Second, security updates are semi-automatically deployed to millions
of Ubuntu systems and need to be regression tested before being released.
Don't be fooled by the fact that they are available for free; this is not a
trivial service.

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

System->About Ubuntu.  Slow to start, but discoverable enough.

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

The vast majority of Ubuntu users don't have an IT department supporting
them.  The development team must make sensible choices on their behalf.

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

That is a different subsystem, unrelated to alternatives (fortunately), and
is a more natural way to solve the problem.

> > [backports]
> 
> 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.

You can cherry-pick what you want; it simply isn't very convenient to do so.
apt-get install <package>=<version>, for example.  If its administrators
wanted it to work this way, the repository could trivially be set to not
automatically upgrade packages unless the user requests it.

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

I encourage you to take your suggestion to the backports team directly.  I
believe they're at ubuntu-backports at lists.

-- 
 - mdz