Future Debian release strategy suggestion

[Mark Shuttleworth <marks@thawte.com>]

Hi all,

One of the really neat things about Debian is the ability to
upgrade individual bits and pieces without major upheaval.
However,  that adds a lot of complexity.

It strikes me that the majority of the crucial stuff is in
the BASE package set,  and I've been thinking if we can't use
this to "speed up" Debian release cycles without compromising
flexibility.

I propose this:

   - that we define a set of CORE packages - analogous to the
     current BASE set.  These should be upgradable "in one piece"
     as well as piecemeal.  The version of the CORE set you have
     defines the version of your Debian release.

   - that CORE sets are released every three to six months, and
     that this is where the majority of the coordinated work goes.

   - that other "non-core" packages gain the ability to depend upon
     a given CORE release,  like "1.1" or "1.2".

I'm basing this all upon the assumption that the non-CORE stuff
will continue to work after upgrading the CORE.  For example, with
the 1.1 release,  we would simply have released a CORE that could
happily run ELF executables (libc5 and newer ld.so etc)  rather
than wait for the WHOLE of Debian to shift to ELF.

I'm also considering the fact that some developers are fantastic
about keeping up-to-date,  while others  (like myself :-() are
often behind.  We don't want slow people like me to hold up
major releases.

We could "roll" the non-CORE stuff as well,  and enforce newer
rules on newer non-CORE packages.  Again using the 1.1 release
as a test case:  we could have created a 1.1 CORE and then a 1.1
tree of packages,  saying that only ELF packages could go in 1.1.

This way one could easily move to ELF by upgrading the CORE and
the other packages as they became availabe.

I really admire and respect the distributed development strategy:
it has worked for Linux,  for Debian,  and many other projects.  I'm
a firm believer that in five year's time most commercial UNIX
platforms will ship with a lot of GNU code simply because the
motivating factors and power of GNU development must result in more
comprehensive and often better quality code.

However,  I think one needs to acknowledge the ease with which
such projects can get bogged down,  and to design their management
structure so that they do not get left behind if individuals or
sections straggle.


Whew!  'Nuff rambling. ;-)

Cheers,
Mark

--
Mark Shuttleworth
Thawte Consulting cc.