Re: Wanted: Volunteer to code a Patchbot

From: grumph@pakistanmail.com
Date: Wed Jan 30 2002 - 12:14:45 EST


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 kernel.org and linux-kernel as they pass initial
  filtering
----------------------------------------------------------

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

_______________________________________________________________________
Get your free @pakistanmail.com email address http://pakistanmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



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