At 07:33 PM 29/01/02 +0100, Olaf Dietsche wrote:
>How about extracting patches from lkml with procmail?
>
>---cut here-->8---
>:0 :
>* ^sender: linux-kernel-owner@vger.kernel.org
>* ^subject:.*patch
>{
> :0 Bc:
> * ^--- .*/
> * ^+++ .*/
> linux-kernel-patches
>}
>---8<--cut here---
>
>This recipe has its limits, but it's a start.
Actually I was sort of thinking that maybe part of the problem with our
current system is the noise-to-signal ratio of lkml itself.
Perhaps it's time we set up a specific lkml-patch mailing list, and leave
lkml for discussions about the problems. Have a script that posts general
details about patches on lkml when there is a post to lkml-patch if you
like, so people know and can go and take a look if they want. If you get
complex, it can vet the patches to see if they apply, before pushing them
to the list. It also goes well with some sort of patch tracking system (who
says we can't use a mailing list as a distribution mechanism), if that gets
the go ahead, while not requiring it.
Another possibility (or could even be combined) is that perhaps we need to
start separating the mailing list at the code tree level.
eg: The "development" tree (lkml-dev which would currently contain 2.5.x)
from the "stable" tree (lkml-stable which would currently contain 2.4.x)
from the "older" trees (lkml-old which would currently contain
2.2.x/2.0.x), at the mailing list level.
That way, people can concentrate on a specific tree (eg: Linus could
concentrate on 2.5.x), without getting inundated with all the other stuff.
This progresses easily when the next "stable" branch hits, so that the
"dev" list can keep talking about what they plan to do while waiting for
the stable to fork into the new development tree, and the previous stable
joins the ranks of the "old" kernels, where it might possibly still get the
occasional fix.
By reducing the noise (and hey, there is a reason people black-list certain
subjects on lkml apart from personal/flame war issues), people can
concentrate on the facts. The less noise (the less traffic?) the more
likely every message will be read, patches will be checked, etc. Especially
when you have other "duties" apart from maintaining kernel code, it's not
always easy keeping up with lkml.
Stuart Young - sgy@amc.com.au
(aka Cefiar) - cefiar1@optushome.com.au
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
-
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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:11 EST