Karmic 9.10 new kernel BAD!

[Avi Greenbury]

Christopher Chan wrote:
> 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.

I can see the feasibility, and some of the advantages. It just doesn't
appear to line up with my priorities as well as it might (and apparently
does with yours).
I'm not particularly opposed to the idea, really, I just thought I'd
suggest why it isn't implemented in Ubuntu.

> > What's wrong with upgrading to a newer release? That way
> > _everything_ gets new features.
> >   
> 
> Bugs. No irony here though.
> 

But you *always* get bugs on upgrades. I want the upgrades with the most
bugs in to happen rarely and at some pre-warned time. And, ideally, to
be able to delay them without delaying the security upgrades I want.

Of course, the downside is this means a cascade of bugs and
problems and clobbered config files every release cycle, but at least
it doesn't tend to happen in between.

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

Ubuntu's certainly organised in such a way as to lean towards Debian's
model. I don't know how much of this is necessitated by the means
through which packages come from Debian to Ubuntu.

> If those ppas were advertised, fine.

Yes, they do need to be more publicised. I wasn't aware of them until I
decided to work out why no-one in Ubuntuland seemed to be suggesting
apt-pinning to anyone, which is definitely the wrong way to find out
about them.

> I don't think the problem was in shipping Firefox 3 beta. The problem 
> was in how it was done. You can have both.
 
I thought the issue was that they could either ship with 2.x and
support it longer than Mozilla would, or ship with 3.x beta and support
it *before* mozilla did, since the policy is to not change major
versions during a release?
I'd certainly have been pissed if an apt-get upgrade broke my firefox
and all its extensions. Though, I suppose, that'd be more down to how
it was packaged than the fact that the upgrade happened.

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

If this is a routine thing, though - the automatic updating of
userland apps - what do you do at the juncture where one feature is
deprecated in favour of another? Implement both? Your current example
doesn't ask for changes to featuresets so much as additions to it, but
some updates are bound to. 
Or, for example, when an automatic upgrade gives you Firefox 3.5, and
breaks compatibility with several of your Firefox 3.somethingelse
add-ons.
I'm not overly familiar with the range of userland applications that
one might want to upgrade frequently, perhaps it is entirely possible
to describe a collection which can always be upgraded without breaking
anything, but I'd _always_ want my system to default to the side of
caution. 

--
Avi Greenbury
http://aviswebsite.co.uk ;)
http://aviswebsite.co.uk/asking-questions