[lkml]   [2001]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The direction linux is taking
Rik van Riel writes:
> On Thu, 27 Dec 2001, Richard Gooch wrote:
> > If you get this working nicely, it might even be a generally useful
> > thing. A set of perl scripts and easy interface commands could prove
> > popular. I would certainly find it convenient to have a patch
> > retransmission system that re-sent patches every time a new pre-patch
> > came out, and emailed me when the patch no longer applies.
> ... or compiles, or applies with an offset

Yes, that was implied. If a patch doesn't apply 100% cleanly with no
fuzz, it should be de-queued and the patch log sent back to me. I'd
want to go in manually and see what's changed (harsh, but reduces the
potential for bit-rot).

> > If it could automatically de-queue when the patch is applied, or when
> > I manually remove it, that would be even better.
> ... or when somebody replies to the patch and the reply
> gets caught by a program invoked from your .procmailrc

Yes. But be careful here. I don't want a DoS attack on my queue just
by having people reply to patch announcements.

> If Linus replies he has seen the patch, don't keep
> bombing him.

Yes, although it might be hard to classify properly. A message like
"not now, I'm busy, send it later" shouldn't de-queue.

> Of course when the patch gets dequeued, the program should
> send you a mail with the reason.

Always. I think I'd also want to be notified every time the patch is
sent upstream. I like to know things are still working.

> > And if I make an update to a queued patch, it obsoletes the old one,
> > that would be good too.
> Good one, this needs to be added.
> Any more requirements / ideas / volunteers / ... ?

I was thinking some more about this in the shower. I'd want some kind
of hierarchical tree processing, that supports multiple kernel
versions (and hence upstream maintainers) and multiple patches per

MAINTAINER (file with my email address)
UPSTREAM-MAINTAINER (file with email address)
official (symlink to kernel/v2.4)
build (symlink to build tree)
configs/ (directory of config files to try)
patch.gz (symlink elsewhere)
comment (file with "Hi, Marcelo, this does...")
configs/ (directory of config files to try)
patch.gz (symlink elsewhere)

UPSTREAM-MAINTAINER (file with email address)
official (symlink to kernel/v2.5)
build (symlink to build tree)

You get the idea. The config files are used to do test compilations,
and it would be nice if I could tag some config files so that the
resultant kernel and modules are moved into some other place. Perhaps
just by invoking a user-specified script. The per-project config files
supplement the per kernel-version config files.

The script which manages this should be lightweight enough to process
the tree every minute (so that newly queued patches are sent quickly)
and should be designed to also work with a .procmailrc recipe that is
called when your local mirror is updated.

Probably files like MAINTAINER and UPSTREAM-MAINTAINER should be
scanned for in every directory, so that files further down override
ones above. Maybe I have a networking patch that I want to send to
Dave rather than to Linus.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.109 / U:2.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site