[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.074 / U:22.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site