PROPOSAL: New NEW development model

[John Richard Moser <nigelenki@comcast.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In lieu of the recent unpleasantness[1] about the new development model,
and of some unexpected nastiness[2] as well, I propose that a very
slight modification be made to the current development model.  This
would merge the previous and new development models (as far as my
understanding is on them) and create a solution for all.

[1] http://lkml.org/lkml/2004/10/22/497
[2] http://lkml.org/lkml/2004/10/26/155

Previously, there were "Stable" and "Development" branches.  The
"Stable" branches, such as 2.2 and 2.4, would stagnate, and rarely have
backported features.  The "Development" branches such as 2.3 and 2.5
would be hammered and mixed with patches, then cleaned up until they
were fairly stable.  Then they'd be hammered with more patches, then
cleaned up, then frozen, cleaned up until "stable" and then released.

Under the new development model, the "Stable" branch appears to be more
"volatile."  New patches and heavy VM and scheduling changes are freely
added, as long as they're stable.  It's not quite "Unstable," but it's
closer to "Development" than "Stable."

I propose that a new development model involving "Stable" and "Volatile"
branches be made.  This would allow development to progress, but still
provide a stable kernel for patch maintainers to work with.

The "Stable" kernel will be the even releases, 2.6 2.8 3.0 and so on.
These should only have security fixes and bug fixes.  No backporting
should be done.  Drivers are a grey area; although this development
model aims to evade the backporting of drivers.

The "Volatile" kernel will be the odd releases, 2.7 2.9 3.1 and so on.
These should follow the current development model of 2.6; new
schedulers, new VM, new drivers, new features all around should be
thrown at the "Volatile" kernel *IF* *THEY* *ARE* *MEANINGFULLY*
*STABLE*.  In this way, the "Volatile" kernel will be suitable for
general use, and will remain fairly "stable."

A stable release cycle should be set up.  Approximately once every six
months, we'll say for example January 31 and July 31 to avoid the whole
Christmas/New Years holiday glob interfering around Jan., the "Volatile"
branch should be frozen into "Stable."  At this point, the new "Stable"
will immediately be equivalent to the latest state of the previous
"Volatile."  Also, because "Volatile" does not break to wait for
"Stable" to "Sableize," it would immediately fork to the next "Volatile"
series.

In effect, there will be no freezes ever.  Once every 6 months, Volatile
will fork into Stable and the next Volatile simultaneously, without a
pause.  Because Volatile will be continually kept up as a functional,
usable kernel as 2.6 is now, there will be no need for a grace period
for bug fixes.

Comments?

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBfoQihDd4aOud5P8RAvMWAJwKqPxmwD6lMFVchDlhf2RrujhsIwCgkTrZ
a6uQLECNDF68nfC4mMCTX8g=
=HLYr
-----END PGP SIGNATURE-----