Messages in this thread | | | From | grumph@pakistan ... | Date | Wed, 30 Jan 2002 18:09:22 +0100 | Subject | Re: 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 - 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/
| |