-----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-----
On Tue, Oct 26, 2004 at 01:06:42PM -0400, John Richard Moser wrote:
> 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.
This is not useful to distinguish your "suggestion" from the status quo.
-- wli
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Lee Irwin III wrote:
| On Tue, Oct 26, 2004 at 01:06:42PM -0400, John Richard Moser wrote:
|
[...]
| This is not useful to distinguish your "suggestion" from the status quo.
|
Help me out here, what's the status quo?
|
| -- wli
|
- --
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
iD8DBQFBfpZkhDd4aOud5P8RAnMyAJ4nbHZB6+2bdCxlu3bF4VXcwYhcAwCggV/I
iU6/kloB9EgiCzKVAGC4cSc=
=JuRT
-----END PGP SIGNATURE-----
On Tue, 2004-10-26 at 13:24, John Richard Moser wrote:
>
> | This is not useful to distinguish your "suggestion" from the status quo.
> |
>
> Help me out here, what's the status quo?
Pretty much exactly what you described already. Instead of "Volatile"
being name 2.7, it's essentially 2.6.N-rcX. (Or whatever Linus has
chosen as the new naming convention for as yet to be released stuff.)
At least that's how your proposal reads to me.
josh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh Boyer wrote:
| On Tue, 2004-10-26 at 13:24, John Richard Moser wrote:
|
|>| This is not useful to distinguish your "suggestion" from the status quo.
|>|
|>
|>Help me out here, what's the status quo?
|
|
| Pretty much exactly what you described already. Instead of "Volatile"
| being name 2.7, it's essentially 2.6.N-rcX. (Or whatever Linus has
| chosen as the new naming convention for as yet to be released stuff.)
|
| At least that's how your proposal reads to me.
|
That's the point. I'd like the current model to split off the
development into a separated branch, and do periodic stable releases. I
think this would allow a much cleaner operation than simply consistantly
enhancing the Stable branch. It's not that 2.6 is
unstable/hackish/crashy/etc, it's that development away from mainline is
more difficult which worries me.
I'd like to make a quick note here that "bugfixes and security updates"
should be trimmed to just "bugfixes," since usually "security updates"
just means "bugfixes for security holes." I'd like to avoid confusion
with security updates such as new LSM hooks and SELinux extensions etc etc.
It would still require Linus to make periodic intermediate releases on
the Stable branch for bug fixes; and someone would have to backport such
bugfixes from Volatile, where they'd probably be found. So there's some
upkeep, but minimal.
The point of restricting this upkeep as much as possible-- to the point
of allowing only bugfixes-- would be to keep pressure off the Stable
line maintainers. If release periods are approximately every 6 months,
new drivers and features such as schedulers will be available every 6
months. No need to waste time and effort backporting what's soon to be
stable anyway.
As for heavier work such as full scheduler rewrites, they could chase
Stable and go into Volatile; although it may be a good idea for such
things to make themselves known so that Volatile (and subsiquent
Stables) can avoid overlapping work, making it difficult for the side
project to keep up.
Still, a month or two to adapt to a new task scheduler out of 6 months
leaves 4-5 months per stable release if the Volatile branch decides to
hack up the scheduler. This is still a better scenario then "VM and
scheduler infrastructures may change on any given release."
So OK, that's what's good here; so what's wrong with it? We've already
established that there will be a minimal level of added work for a
maintainer to keep the Stable up. Are there any other drawbacks? If
not, any objections to trying to sell this one to Linus and Andrew? :)
| josh
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
|
- --
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
iD8DBQFBfqSEhDd4aOud5P8RAt6QAKCBdRm+e5yHhL7xmTZuAbIYIhzXXwCaAhxF
DsAfQhC3R4gy87LaB5DMXnM=
=7KX/
-----END PGP SIGNATURE-----
John Richard Moser wrote:
> Still, a month or two to adapt to a new task scheduler out of 6 months
> leaves 4-5 months per stable release if the Volatile branch decides to
> hack up the scheduler. This is still a better scenario then "VM and
> scheduler infrastructures may change on any given release."
>
>
>
> So OK, that's what's good here; so what's wrong with it? We've already
> established that there will be a minimal level of added work for a
> maintainer to keep the Stable up. Are there any other drawbacks? If
> not, any objections to trying to sell this one to Linus and Andrew? :)
Knock yourself out, I would be happy if they would just agree not to
take features out of a stable series or intentionally break them. If new
features don't break the old ones I don't think there's a persuasive
argument to keep them out.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me