Re: My thoughts on the "new development model"

John Richard Moser
2004-10-27T05:27:02Z

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

Marcos D. Marado Torres wrote:
| On Tue, 26 Oct 2004, Ed Tomlinson wrote:
|
|>>> 2.4 tree is still the best solution for production.
|>>> 2.6 tree is great for gentoo users who like gcc consuming all CPU
|>>> (maxumum respect to gentoo but I prefer debian)
|>>
|>>
|>> The issue is that Linus _has_ changed the development model. What we
|>> have
|>> now is more flexable and much more responsive to changes. This does
|>> lead to stable releases that are not quite a stable as some of the
|>> previous
|>> stable series... This is why I suggest a fix/security branch. The
|>> idea being
|>> that after a month or so of fixes etc it will be a very stable kernel
|>> and it will
|>> not have slowed down development.
|
|
| The sole existence of this discussion prooves that there's already the
| need of
| a new step. But why trying to re-invent the wheel? Yes, relating to 2.6
| we need
| already a "very stable kernel" and a "not-slowed down development
| kernel". When
| it happened in 2.4 2.5 was created. Isn't all this just the indication
| that we
| need a 2.6 development like 2.4 is, and we need 2.7 to be created?
|

Another shameless plug for me:
http://lkml.org/lkml/2004/10/26/171

Short version to save you reading of my spam:
Let's make 2.7 what 2.6 is now (a relatively stable kernel that gets
relatively stable feature enhancements continuously), rather than what
2.5 was (a hell of a lot of patches and then a hell of a lot of
debugging), and make 2.6 more restrictive than 2.4 in that it should be
strictly bugfixes (including security bugs) and no backported drivers or
features.

I read a page about open source software development once, I don't
remember if it was an article or a book or what; but it said something
I've held to heart for a while: Open source projects tend to follow the
poorly designed development model of alternating between a "stable" and
an "unstable" branch, when it's possible to simply perpetually add
stablized, debugged features straight to mainline after they've been
developed independently on the side.

It is apparent that what we have here is exactly what the author
suggested in place of the stable/unstable cycle; it is also apparent
that this is a naiive model not because it becomes difficult to avoid
bugs, but because it becomes difficult to actually develope on the side
with all of the changes happening to mainline. By combining both
models, a balance is met.

This same model can be implemented as a meta-model (or something) if the
external projects chose on their own which versions to freeze at. This
creates a problem, however, as patches for these projects become
distributed across ranges of versions. Consider having a development
driver for 2.6.7 for an ADSL card; a development driver for 2.6.5 for a
network card; and a development DRM driver for 2.6.10 for a particular
video card. The unfortunate soul having all three of these pieces of
hardware is quite SOL.

On the other hand, there are those who simply get fed up chasing the
volatile codebase of mainline, ad simply wait for it to stabalize.
Unless you throw them their bone, they won't get any work done; this is
not only their problem, but their users' as well.

| Mind Booster Noori
|
| -- /* *************************************************************** */
| Marcos Daniel Marado Torres AKA Mind Booster Noori
| http://student.dei.uc.pt/~marado - marado@student.dei.uc.pt
| () Join the ASCII ribbon campaign against html email, Microsoft
| /\ attachments and Software patents. They endanger the World.
| Sign a petition against patents: http://petition.eurolinux.org
| /* *************************************************************** */

- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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

iD8DBQFBfzFZhDd4aOud5P8RAiTmAJ9obM88F5YW29Rcke3oKrWngs/rRACaAxqZ
BBoLsEO2QdBIJfZlBvGpZHk=
=hMNm
-----END PGP SIGNATURE-----