Karmic 9.10 new kernel BAD!

[Avi Greenbury]

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.

> 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.
What's wrong with upgrading to a newer release? That way _everything_
gets new features.

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?

> 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?
These two can be upgraded safely, sure, and it's quite possible and
easy to. I just don't think it should be automatic.

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

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?

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

-- 
Avi Greenbury
http://aviswebsite.co.uk
AIM/Y!  lordandmaker
MSN/G   ialoneambest at gmail.com