lkml.org 
[lkml]   [2002]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
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 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/

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