Release management thoughts for Dapper Drake

[Stephen Hemminger]

On Sat, 15 Oct 2005 06:51:03 +0200
Fabio Massimo Di Nitto <fabbione at ubuntu.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jeff Waugh wrote:
> 
> > 
> >  2. Ship both Linux 2.6.12 and 2.6.new
> > 
> >     I suggest we ship two kernels with dapper: A well tested and stabilised
> >     2.6.12 for servers and a nicely up-to-date 2.6.new (probably 2.6.14) for
> >     desktops. This does mean extra work, but while we're tracking the fresh
> >     branch, we can fold fixes back into the 2.6.12 branch. Potential gotchas
> >     include: incompatible inotify and udev changes (kernel/userland combos
> >     elsewhere, too), desireable new stuff for servers such as the upcoming
> >     SCSI changes not being backportable to our stable branch (thanks to
> >     James Troup and Daniel Silverstone for pointing these out).
> > 
> 
> Sorry but i strongly disagree with this approach. Maintaing 2 kernels is not
> just a bit of extrawork. It is confusing and it will create a lot of extra
> work.
> What we will discuss at UBZ as planned in the wiki, is the possibility to use
> the same vanilla kernel (.14 or .15 or whatever, time will tell) for both server
> and desktop. With the latter patched with more extra interesting stuff.
> Also as you mentioned yourself that will require mostlikely 2 sets of userland
> tools to match the running kernel and that's definitely adding an extra and easy
> point of failure.
> 
> Also keep in mind that preparing security releases for older kernel becomes
> exponentially more complex with time, given the amount of code that changes
> between kernel releases.
> 
> Fabio

A couple of comments. First, hardware changes pretty fast and backporting to support
new hardware on old kernels will get real painful after a couple of years. I predict
that after 3 years it will be really hard to run 2.6.12 on a current piece of hardware.

Also, I have heard that some of the other "Enterprise" versions do things like roll
in the latest kernel.org version, then set the version number back to the what ever
was first shipped with that release. So the latest RHEL kernel may really be more like
2.6.10 even though it is called 2.6.8.  This is because a lot of third party products
(ie. Oracle), are "certified" against a release number. So it is okay to change the
kernel internals just not the version (go figure).



-- 
Stephen Hemminger <shemminger at osdl.org>
OSDL http://developer.osdl.org/~shemminger