LTS and release methodology

Sat Jul 12 09:00:42 UTC 2008

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

The only ones we would have to care about are the build systems for
major apps: Firefox, Openoffice, etc. I guess they have such
abilities.

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

OK, I will try to test it. Given my poor packaging skills and little
spare time it will take much longer than if it was done by person who
already knows application packaging/build system.

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

But only because it supports multiple parallel versions. So I guess
you support my point that parallel versions are useful?

>> And I really don't think the one from Dapper would work on Hardy.
>
> I would be surprised if it stopped working.

I will check it.

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

Simple notification popup "Your OpenOffice 2.3 reaches end of
lifecycle next month" would be doable and simple. Sending e-mail to
customers would be even simpler. Limited transition support packages
would be targeted at IT departments and are added value for transition
periods, so I think IT departments would be aware how they have to
handle end of lifecycle announcements.

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

It is not porting security changes, it is backporting security-fixed
package again. Example from my Firefox packages: I am taking Firefox
2.0.0.14 from Feisty and backporting it to Dapper. When security
update (Firefox 2.0.0.15) appears I am not taking security fixes and
apply it to 2.0.0.14. Instead I am taking Firefox 2.0.0.15 from Feisty
again and backport it to Dapper. It is much simpler (but of course it
also requires regression testing).
I am aware it is not always possible with each application and
lifecycles might come into play, but it is possible for some apps.

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

Novice user would not find it. And on Kubuntu it is even harder.
Anyway, asking app version is equally difficult and can be guided by
helpdesk person the same way.

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

Yes, so the defaults would be the same as now. Nothing changes.
Except from the fact that when default application version does not
work, user can get to know on support forums/blogs/etc. how to
run/install alternate version and not get one of the responses he gets
currently:
a) Install previous distribution release
b) Wait for next distribution release
c) Wait for fix (which might never come)
All of them require significant changes and take significant time,
while users expect they can do the job immediately. Additionally b)
and c) are not reliable (bug might not be fixed), a) and c) might not
work for other reasons (because other release might have other bugs
which are blockers). The most reliable is a), but let's be honest -
how many people will reinstall system to get their office job done? So
they go back to Windows.

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

If you are talking about apt pinning, it is by no means trivial.
Adding backports repository causes information that there are updates
ready. It takes explicit actions from user to not update packages from
backports. And if security fixes appear for package in main, he would
have to check it manually and carefully update to proper version, not
to version in backports. This is not security-friendly or
user-friendly.
Maybe if Ubuntu shipped with apt settings which would make backports
repository lower priority and would require explicit installation of
given version from backports it would be OK, but AFAIK it is not the
case.

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

I will.

BTW. I have checked PPA and it appears to be broken in the same way as
backports - I cannot create separate components in archive. I would
have to create new team for each set of backported packages.

Regards
-- 

	Krzysztof Lichota