Karmic 9.10 new kernel BAD!

[Christopher Chan]

Avi Greenbury wrote:
> Christopher Chan wrote:
>   
>> Avi Greenbury wrote:   
>>     
>>>> If there is anything worth contributing, it may be my opinion that
>>>> there should updates/upgrades to 'broken' packages in Hardy (what's
>>>> the point of a LTS again?) such as pidgin not talking to Yahoo or
>>>> Open Office not opening docx files.
>>>>     
>>>>         
>>> The LTS bit refers to support, and has no necessary bearing on
>>> stability.
>>>       
>> Never mentioned stability. Yeah, I know LTS = Long Term Support.
>>     
>
> You did. There are two meanings of stable, it can mean a system doesn't
> fall over much, or that it is unchanging.
> It is the latter which, for example, is used to denote Debian's Stable
> branch. This is what I meant when I said that being an LTS
> didn't necessary dictate the stability.
>
>   

Oh certainly we do not want kernels with new interfaces yet again.

>> I still fail to see why I should upgrade to a new distribution to get 
>> something that is non-core operating system wise and therefore does
>> not required that you test every package that uses it.
>>     
>
> Because if I've deployed 400 installs across a company, I don't want
> bugs to be added, and the easiest way to add bugs is to add features.
>   

Of course. However, that does not mean new features cannot be added to 
an LTS release. Redhat can add new features to their RHEL4 kernel and 
other core packages after a few point releases, so it is not something 
that is not done or unfeasible. You just have to test everything before 
you let such updates loose.

> What's wrong with upgrading to a newer release? That way _everything_
> gets new features.
>   

Bugs. No irony here though.

> If the software in 8.04 was continually upgraded and changed, what
> would be the difference of sticking with 8.04 rather than upgrading to
> 8.10?
>
>   

You have missed the point. I specifically pointed to 'consumer' packages 
and not 'provider' packages such as the kernel, glibc or other system 
libraries. pidgin/openoffice do not have other packages dependent on 
them for example. The different would be that there is a known set of 
libraries that developers can depend on to develop their applications 
and they can release updates/upgrades of their application based on the 
fixed set of system libraries. pidgin and openoffice are not system 
level packages. You do not have to test everything. Just the new pidgin 
and openoffice packages in this scenario.

>> Neither pidgin  nor OpenOffice have that many if at all any packages
>> that depend on them. An upgrade of OpenOffice will not require
>> extensive testing to make sure nothing breaks.
>>     
>
> This leads to complication when people don't know which packages have
> been declared minor enough that an upgrade "wont break anything". And
> who would get to decide what can be upgraded, and how on earth does one
> test it?
>   

So is it the way Ubuntu is organised that is the problem? How about 
system packages in a 'core' repository and applications in a 'consumer' 
repository that depend on packages in the 'core' repository then?

> These two can be upgraded safely, sure, and it's quite possible and
> easy to. I just don't think it should be automatic.
>
>   

Well, I guess in the case of OpenOffice maybe not. But in the case of 
pidgin, I fail to see a reason. The new version will not have any GUI 
changes, just the Yahoo plugin being replaced with one that works.

>>> I wouldn't expect an LTS to keep version parity with newer,
>>> shorter-term releases, because then it *is* those releases and is no
>>> longer an LTS.
>>>       
>> Right, even if a package is no longer usable because it is too old
>>     
>
> How does a package become 'too old' to be usable? It's not like it
> wears out. LTSs are only three years long, and it's quite easy to
> replace individual 'too old' packages through ppas or apt-pinning.
>   

If those ppas were advertised, fine.

> This is where the furore over shipping the beta of Firefox 3
> came from - an upgrade from 2.x to 3.0 is not something you do with a
> stable release, it changes too many things.
> Would it be worth all the aggro of an upgrade from FF2.x to 3.x during
> an LTS, with all the accompanying incompatibilities and configuration
> changes?
>
>   

I don't think the problem was in shipping Firefox 3 beta. The problem 
was in how it was done. You can have both.

>> and it is not something that is like a foundation as some packages
>> like glibc are. Redhat adds new features let alone 'features' or at
>> least backport code to older versions of software of fixes in newer
>> versions to RHEL. That, in my opinion, is what a useful LTS
>> definition is. Core packages do not or rarely get upgrades/backports
>> while 'end user' packages will be upgraded as is necessary and
>> possible.
>>     
>
> I'm not familiar with RH's release process, and I'm not meaning to make
> you come round to the idea that an LTS is not supposed to change its
> featureset. All I'm trying to explain is that there is a point to an
> LTS whose featureset doesn't change, and there is some demand for it.
>
>   

Well I am not asking for CHANGES in feature sets. In the example about 
Redhat, they did not change any features, they just added some new ones 
but this was at the system level. End user level changes is certainly 
not as hard and nor does it require the same level of testing.