Wanted: Volunteer to code a Patchbot
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 kernel.org and linux-kernel as they come in.
----------------------------------------------------------
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