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/