long term support, multiple kernels, etc

Mark Shuttleworth wrote:
> 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).
>> 
>>

> I'm still open minded on either strategy: two kernels of the same
> upstream version, or two dfferent kernels.

I believe that 2 kernels of the same upstream version are more than fine.
The main thing to avoid on a server kernel is to avoid all the bling
we push into the desktop. See for example ACPI latest code or alike
that are sometimes origin of plenty of bugs (while they still solve
many others).
We already have this infrastructure in place (to patch per flavour) so
the overhead to discriminate patches becomes much lower than maintaing
two upstream kernels.

Just to give you an idea, in the last kernel security release with about
7 vulnerabilities to analize, it took me 3 days of patching and building,
one day of testing + upload to cover warty/hoary/breezy.
Already patching breezy was an issue since some patches were made on top of
2.6.14rc.
Clearly if we add 2 extra kernels the overhead is pushed high and very fast.

Also, .12 and .14 in dapper will still need a lot of love in terms
of bug fixing. IME we will land with a .12 that will look more like a .14
with a different number.

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

.14 will get the same kind of love we gave to .12. The reason why .12 seems
so stable is because we did start releasing it already in .12rc2. That gave
us quite a long time to stabilize and test. Ben and I already agreed
to do the same for .14 that's more or less waiting for Dapper to open
(modulo some reorganizations due to git).
This approach has been good in breezy and i see no reason why it shouldn't
work in dapper.

> 
> To what extent is the latest userland love a desktop issue?

The main issue is that userland and kernel must be in sync. Let's take for
example the transition we had between hoary (.10) and breezy (.12).
hotplug and udev (mainly the latter) mechanism have changed a lot.
udev basically requires a .12 kernel to work properly. Similar
situation are likely to happen all the time.
It is simply not possible to keep 2 versions of udev around for obvius reasons.
Or for example parts of our shiny cluster suite needs to be synced
between kernel and userland otherwise it simply doesn't work.

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

Unfortunatly expressing this dependency is extremely complex.
Assuming we really want to do so, it will kill the option for users to use
custom kernels on their machines.
While we clearly don't support that enviroment, i still use that option myself
to test patches and bug fixes.. and having to see ubuntu-desktop+ removed
from my machine for a test, can be annoying.
I see the same happening on user machines.. that won't be good.

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

Yes i perfectly agree, and that's why in my suggestion, -server was only a more
conservative flavour of the current upstream release.

As it is in our build system, adding a flavour is a couple of hour work
(including a build) and becomes almost no overhead to maintain since it
gets approx the same love as everything else and the infrastructure is there
already.

So for example a security patch that lands in dapper, will automatically
propagate to desktop and server kernel without any duplicate effort.

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

Debian uses one kernel only. They make no difference but they are also
much more conservative from the beginning. They simply don't apply tons
of patches as we do (read this as more drivers, extra features and so on).

We will for sure look at what RHEL and SUSE do.

Fabio

-- 
I'm going to make him an offer he can't refuse.