Re: Wanted: Volunteer to code a Patchbot

Date: Wed Jan 30 2002 - 12:09:22 EST

I did some thinking just before this thread surfaced.

What can a patchbot be trusted to do properly? (see below)
Linus got his style of working and he's got no intention whatsoever to
change that. So what is needed is a bot that works according to Linus'
taste, but goes behind his back when it comes to informing the poor
patch submitters....

As always, simplicity rules.

None of this relies on a bot handling actual patching of code in the
tree. A live, human (most of you, I assume) being will have to review
and manually apply the patch.

None of this requires Linus to change his habits, he could still apply
any patches sent to torvalds@transmeta. Trusted people could still send
Linus patches directly.

But the newbies and untrusted guys without an established relationship to
a trusted kernel developer get a little help to keep their patch updated.

It is not going to help on bad person chemistry or bad code. But it
could weed out the obvious non-starters and help people get it right,
without bothering busy kernel developers.

What can a patchbot be trusted to do properly?
- receive mail sent to: patch-2.5-linus@kernel or patch-2.4-marcelo@kernel
 (you get the idea; version and tree)
- patch-id assignment for tracking of patches accepted by bot
- sender authentication/confirmation, as for mailing list subscriptions
- verify that patch
        - applies to latest tree
        - isn't oversized (by some definition)
        - is correctly formatted
        - contains a rationale (in some predefined format)
- route patch to correct maintainer(s), based on the files it touches
        (may require some initial work)
- inform sender that patch was forwarded to <maintainer>
- inform sender that patch was automatically rejected because it:
        - does not apply to latest tree
        - is too big/touches too many files
        - does not compile (hardware reqs.? OSD labs?)
        - does not contain aforementioned rationale
        - isn't formatted according to CodingStyle (Does current code?)
- inform sender that patch did not end up in next snap of tree,
        possibly because of:
        - conflict with other patch
        - a human didn't like the taste of it (-EBADTASTE)
        - maintainer has not reviewed the patch yet
        (use the above assigned patch-id to detect if patch was applied)
- ask sender to rediff, review and resubmit patch
  The bot could do this by itself. But it isn't linus-style.
  The sender should maintain his own patch.
- inform the sender how to kill a patch-id from being processed
- automatically kill patch-ids from being processed if sender does not
  respond within <time>
- killfile abusers (needs policy)
- publish patches on and linux-kernel as they come in.

Will Linus immediately killfile mail sent from this bot?
Will hpa host it at
Will someone write the code if it gets thumbs up from linus/hpa?
Is it going to make a difference?

Get your free email address
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

This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:21 EST