>
> >>> This email address could also CC: Linus everything it receives so
> >>> that even if this was not a plausible way for Linus to traditionally
> >>> receive patches others could use it to see what people have submitted,
>
> This is great, since Linus does not have to change his ways.
> We get a web page full of patches, and he gets them in email.
> Procmail could even detect mangled patches and fix or return
> them. Good patches could be converted into a format he likes.
> (uudecoded gzip & raw patches last I heard, without MIME)
>
> Headers like "From:" and "Cc:" ought to stay intact too.
Part of the idea was to not create any more work for Linus, however
it would be nice to be able to get some feedback from him. This setup could
also email any patch that hasn't been 'cleared' by the patch-submitter to
Linus once the patch has become a week old.
This takes some of the work off of the patch-submitter, but replaces
it w/ a req. that the patch submitter submit a 'cleared' notification so that
Linus doesn't keep getting patches over and over.
However, this moves the load of work from Linus to the various
developers, not that sending an email to the like of 'PATCH: XYZ, ACCEPTED'
is all THAT much work, and in fact a better system would be to email the patch
to Linus and the developer where either can just hit 'reply' and type 'ACCEPTED'
in the body or subject or something and have the patch be updated as 'ACCEPTED'
and have it no longer sent to Linus every week.
> > Well, in the end it is for Linus to decide, though I agre it would
> > seem easier provided one had a good news-reader.
>
> That could be considered "work".
>
> If the system makes Linus change his ways, it will fail.
> He can't be expected to change the way he likes to work.
Ultimitely it's up to him of course, this was just another
suggestion.
Stephen
-
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/