long term support, multiple kernels, etc

Jane Silber wrote:
> Hi all -
> 
> I had to see a picture to get my head around the implications of
> multiple kernels and long-term support, so  I've attached it in case it
> helps anyone else think about this.  I wanted to see what sort of
> security/supportability quagmire we might be getting in, so this
> represents the scenario where we have different kernels for Dapper and
> then continue on that path. So in some senses this is a worst case
> scenario (i.e., continue to have different kernels for desktops and
> servers for each release), but I also think that once we go down the
> path of having separate kernels, it will be difficult to pull them back
> in line, so in some ways I think this is also a realistic scenario.
> 
> Also, I've assumed that we will do longer life cycle releases every 2
> years, but this is not a decision or commitment to do so - just an
> assumption for this drawing.
> 
> You'll note that worst case scenario ends up being 9 kernels being
> supported concurrently, but even as early as a year from now we could
> potentially be up to 5.

Hi Jane,

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

Anyway since we are it, my proposal did never include to support 2 upstream
version (as Jeff suggested). This is simply overkilling. We have no resources to
do that and it is a complex approach for different reasons.

The idea behind of desktop/server kernel is still to share the same source
but apply more dekstop patches to the desktop kernel (like suspend/resume code
that we don't need in server) or differ them in some configuration aspects
(we might want 64G ram support on server).
This will make security support way easier. Patch one source, propagate the fix
to world.. profit.. ;)

Supporting old kernel becomes exponentially more complex in relation to their
age. The kernel development is fast and wild. I expect that we will start
hitting backport problems after 12 monhts of a kernel release like we are
already doing now for warty. There is nothing we can do about it other than
spend more energy in that direction.

This is more or less the situation if i understand your question right.
The number of kernels to support will clearly increase if we support so many
releases at the same time, but carry kernel from distro foo to distro foo+1 is
not an option either, given that new hardware is not supported in kernel foo.
And backporting is no no no no.. it's extremely complex and time consuming.

Fabio

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