[lkml]   [2002]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Wanted: Volunteer to code a Patchbot

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 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> after response from bot.
- automatically kill patch-ids from being processed if patch gets applied in

next snapshot
- killfile abusers (needs policy)
- publish patches on and linux-kernel as they pass initial

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

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