Automating 2.3 patches

Mike Black (mblack@csihq.com)
Sun, 11 Oct 1998 08:13:47 -0400


This is a multi-part message in MIME format.

------=_NextPart_000_0016_01BDF4EF.120F5E00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I've got a suggestion to speed up the 2.3 patch cycle.

We can still keep the benevolent dictator model (thanks Linus!).

What we need to do is speed up the patch testing cycle. This is now =
being done thru the maillist.

Could we put together a web-site that allowed users to vote good/bad on =
patches against Linux releases? Users would test a patch against a =
specific release and then post OK or BAD/WHY on the web site.

This way, users could determine their own level of need/risk in testing =
patches. And, Linus could use the statistics to determine when to =
include a patch in the development kernel (same would be true of the =
stable kernel too). Anybody could go the web site and look at the stats =
for any patch to determine.

This way, the anal retentives could say "I am not dowloading a patch =
until it is 100% safe), the daring would test any patch anyway, and the =
rest of us would pick some point between.

This would put virtually no load on Linus (somebody else would manage =
the web-site --pretty minimial once it's setup).

------=_NextPart_000_0016_01BDF4EF.120F5E00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

I've got a suggestion to speed up = the 2.3 patch=20 cycle.
 
We can still keep the benevolent = dictator model=20 (thanks Linus!).
 
What we need to do is speed up the = patch testing=20 cycle.  This is now being done thru the maillist.
 
Could we put together a web-site = that allowed=20 users to vote good/bad on patches against Linux releases?  Users = would test=20 a patch against a specific release and then post OK or BAD/WHY on the = web=20 site.
 
This way, users could determine = their own level=20 of need/risk in testing patches.  And, Linus could use the = statistics to=20 determine when to include a patch in the development kernel (same would = be true=20 of the stable kernel too).  Anybody could go the web site and look = at the=20 stats for any patch to determine.
 
This way, the anal retentives could = say "I=20 am not dowloading a patch until it is 100% safe),  the daring would = test=20 any patch anyway, and the rest of us would pick some point = between.
 

This would put virtually no load = on Linus=20 (somebody else would manage the web-site --pretty minimial once it's=20 setup).
------=_NextPart_000_0016_01BDF4EF.120F5E00-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/