long term support, multiple kernels, etc

Hi Mark and all Others,

I just read the thread about different kernel "versions" and/or
"flavors". 

So, regarding this, we have informations how RHEL is doing this kernel
revisions, they're using one kernel-revision and enabling some features
for different architectures and feature sets (e.g. smp etc.).
You can have an overview here:
http://www.redhat.com/software/rhel/configuration/

The reality is, that many of the sysadmins who have serversystems with >
<insert your fav number here from 10 up>, are using self compiled,
monolithic kernels out of the kernel source which is shipped by the
distribution. 

So what would be nice to have?

A module orientated and supported kernel for "enterprise" desktop
systems
A kernel source with our patches applied and supported, which can be
compiled by the admin and deployed over several machines via local
package repository or (which is really funny and used in some companies)
via cfengine.

For the server base it would be quite intresting, that we are supporting
a kernel source base, which can be compiled by admin herself and used as
well in a monolithic way.

How to identify the kernel source version for Ubuntu, this is something
for the kernel guys ;)) But we should really have this idea, cause it's
diffrent from others and is a more canonical way ;)

And then we can think about UUN (Ubuntu Update Network). Which provides
dedicated d-i install repositories and bla..this is future music and not
ready to be discussed now ,-)

Regards,

\sh

Am Dienstag, den 18.10.2005, 00:51 +0100 schrieb Mark Shuttleworth:
> Fabio Massimo Di Nitto wrote:
> 
> >I think that my suggestion of having a kernel for server and kernel for desktop
> >has been highly and wildly misunderstood (that's why it was supposed to be
> >discussed in a BOF).
> >  
> >
> Fabio, you and Ben are the kernel experts around here, so your thoughts
> carry a lot of weight in this discussion.
> 
> I'm still open minded on either strategy: two kernels of the same
> upstream version, or two dfferent kernels. I have to believe that 2.6.12
> is a more stable platform for a server edition though, and that it is
> more likely to be a credible server kernel. And at the same time, .14
> will be needed for the latest userland love.
> 
> To what extent is the latest userland love a desktop issue? Is it both a
> server and a desktop issue? Could we say that using the server kernel is
> incompatible with the desktop layers? Could that be enforced in the
> package dependencies? Could we for example have a 2.6.12 kernel that
> would not support ubuntu-desktop for Dapper, but a .14 kernel that
> would? So server guys can have the older kernel if they forego the
> desktop goodies?
> 
> I do have some definite comments on the discussion so far:
> 
>  - we definitely will not do two new kernels for each release. The
> "server" kernel is something new, we should only support one, max two of
> those at ANY time, it makes sense to do them only for the Dapper-style
> long duration releases, and only ever to have two of those in circulation.
> 
>  - we should look to see what RHEL and SUSE and Debian are using for
> their major server oriented releases. I think RHEL is due a release some
> time in the Dapper time frame, what will they be using? Effective
> collaboration and review of their work will help us find low hanging
> fruit, that is much easier to do if we're on the same upstream version.
> 
>