Re: Let's make a small change to the process

[John Richard Moser]

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



Paolo Ciarrocchi wrote:
| Hi all,
| despite I know you are all bored with the " I know how to improve the
| process" email but I want to share with you this idea .-)
|
| Both Andrew and Linus are doing an impressive job so I really don't
| think we need to change the way they are working.
|
| What I'm suggesting is start offering 2.6.X:Y kernel, you did for
2.6.8.1 so...
|
| The .Y patchset contains only important security fix (all stuff you
| think are important) and is weekly uploaded to kernel.org
|

Eww.

2.6.10 got an -rc about 4 days after 2.6.9 went stable.  This would be a
bit too rapid for my tastes; I don't like ideas that potentially load
maintainers.

[...]

| We, of course, need a maintainer for it,

Yes, a little too much to maintain though isn't it?  Maintainers to
continuously upkeep revisions that come out every few weeks potentially?
~ Remember it's got to be able to withstand the test of time for quite a
while; why are people still maintaining 2.2?

| maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
| for a long time), maybe Alan (that is already applying these kind of
| fixes to his tree), maybe someone else... ?
|

Common courteousy, don't volunteer people.  :)

| Sounds reasonable ?
|

Sounds too fast.  I don't predict having a maintainer for each minor
release of the kernel (which is what you're saying here essentially), so
there'd be a need for one or a handfull of maintainers to spend loads of
time backporting fixes to a quickly mounting set of kernels.

I had <shameless plug> suggested an hour or two ago a scheme where the
current development model be based off, but periodic releases be made
"stable," basing on approximately 6 months between releases </shameless
plug>.  I think it's a bit more sane to say that a maintainer may mount
up 4 kernels in 2 years to backport bugfixes into, if nobody else steps
up to the plate to help.

Of course, eventually official support has to be dropped in either
scheme, because the same problem is faced:  We can't expect people to
maintain a continuously mounting number of kernel revisions once the
workload becomes sufficiently high.  A balance must be made between
dropping support for a non-volitile code base, and maintaining a support
period sufficiently long.

- --
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

iD8DBQFBfrg7hDd4aOud5P8RAo5eAJ4/lbCRuNfVM9iNoNaEOBX5wdqTlwCfWUK7
XM9z2dgXmkMWg28xZzlWeMI=
=edrQ
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/