Re: Wanted: Volunteer to code a Patchbot

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 30, 2002 06:09 pm, grumph@pakistanmail.com wrote:
> 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.
> ----------------------------------------------------------

Yes, you have the idea most precisely.  You left out:

  - post the patch to the respective mailing list (the one the patch
    was sent to)

> Will Linus immediately killfile mail sent from this bot?

I don't think so, unless the bot is really poorly designed.  This is *not* 
going to be a spambot.  When the time comes, i.e., when the bot is designed 
in detail, or better, function, we'll ask him, ok?  Or, if he so much as 
scowls in this direction, work stops right now ;-)

> Will hpa host it at kernel.org?

Again, once we know what the details of the bot are we'll ask him, i.e., how 
heavy a resource user it's expected to be, if he even thinks the idea is 
sound, etc.  Right now he could only answer in general terms, so the thing to 
do is produce something concrete, not theoretical.

> Will someone write the code if it gets thumbs up from linus/hpa?

Somewhat unexpectedly, three coders responded to my call for volunteers:
   
   Kalle Kivimaa <killer@iki.fi>
   Rasmus Andersen <rasmus@jaquet.dk>
   Giacomo Catenazzi <cate@debian.org>

I must say, I've been impressed with the insight of all three.  Would you be 
a fourth?  A mailing list has been set up (by Giacomo):

   http://killeri.net/cgi-bin/alias/ezmlm-cgi

> Is it going to make a difference?

Yes, I think it is.  At the very least it will give Linux users a place to go 
and troll for interesting patches, sort of like Freshmeat.  I'm expecting a 
considerably more from it though.  Look no further than your own list above 
to see what it can do.  Which, by the way, bears a remarkable resemblance to 
the list we just hashed out a few minutes ago.

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Rasmus Andersen]

On Wed, Jan 30, 2002 at 06:17:16PM +0100, Daniel Phillips wrote:
> I must say, I've been impressed with the insight of all three.  Would you be 
> a fourth?  A mailing list has been set up (by Giacomo):
> 
>    http://killeri.net/cgi-bin/alias/ezmlm-cgi

It does not matter terribly but the list has been setup by
Kalle Kivimaa <killeri@iki.fi>.
-- 
        Rasmus(rasmus@jaquet.dk)

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 30, 2002 09:29 pm, Rasmus Andersen wrote:
> On Wed, Jan 30, 2002 at 06:17:16PM +0100, Daniel Phillips wrote:
> > I must say, I've been impressed with the insight of all three.  Would you be 
> > a fourth?  A mailing list has been set up (by Giacomo):
> > 
> >    http://killeri.net/cgi-bin/alias/ezmlm-cgi
> 
> It does not matter terribly but the list has been setup by
> Kalle Kivimaa <killeri@iki.fi>.

Oh yes it matters.  Sorry Kalle, and thanks for the fast work.

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Russell King]

On Wed, Jan 30, 2002 at 06:09:22PM +0100, grumph@pakistanmail.com wrote:
> I did some thinking just before this thread surfaced.

(and repeat this message at least 21 times)

Do you think you could please take the time to fix your email setup so
we don't get all these repetitions.

Thanks.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 30, 2002 08:56 pm, Russell King wrote:
> On Wed, Jan 30, 2002 at 06:09:22PM +0100, grumph@pakistanmail.com wrote:
> > I did some thinking just before this thread surfaced.
> 
> (and repeat this message at least 21 times)
> 
> Do you think you could please take the time to fix your email setup so
> we don't get all these repetitions.

It's possible he was the innocent victim of that freemail service, in which 
case, the thing to do is switch to a different freemail service.  Yahoo is 
pretty good.

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[grumph]

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

Re: Wanted: Volunteer to code a Patchbot

[Giacomo Catenazzi]

> 
> <deleted>
> That's the problem.  I have seen at least two attempted starts on a patchbot
> and know of a third (Dan Quinlan was going to do something 1.5 years ago).
> So at this point I want to step out of this discussion.  There is going to
> be no patchbot without a coder to write it, so why spend more time talking
> about it?
> </deleted>
> 
> OK, on a less pessimistic note, I'll make a small effort to find a volunteer 
> to code this, under advisement that it will be a thankless task (everybody 
> will complain about everything) and may not even get accepted by Linus or 
> anyone else (yes, and?).  So here it is:
> 
>    Wanted: a scripting person who has a clue about MTAs and wants to 
>    contribute to the kernel.  Please step up to the table over here
>    and sign in blood, then we will tell you what your mission is.
>    Nobody will thank you for any of the work you do or reward you in
>    any way, except for the right to bask in the glory and fame of
>    being the one who ended the patchbot wars.  And maybe, just maybe
>    get that coveted Slashdot interview.


I can help you.
I'm good in scripting and I know well the RFC{,2}82{1,2}. (But I think
we should not worry much about these RFC.)
Wanted: a good design. I've already tried to design such bot, but I never
found a good and clean way to improve development without to change much
of current behaviour.


	giacomo

Re: A modest proposal -- We need a patch penguin

[Roman Zippel]

Hi,

On Wed, 30 Jan 2002, Daniel Phillips wrote:

> > I'd rather make the patchbot more intelligent, that means it analyzes the
> > patch and produces a list of touched files. People can now register to get
> > notified about patches, which changes areas they are interested in.
>
> But they can already do that, by subscribing to the respective mailing list
> (obviously, the bot posts to the list as well as forwarding to the
> maintainer) and running the mails through a filter of their choice.

What about unmaintained parts?

> > In the simplest configuration nothing would change for Linus, but patches
> > wouldn't get lost and people could be notified if their patch was applied
> > or if it doesn't apply anymore.
>
> OK, it would be nice, but you wouldn't want to pile on so many features that
> this never gets implemented would you?  The minimal thing that forwards and
> posts patches is what we need now.  Like any other software it can be
> improved over time.

That's what I have in mind. What we can already do now is to store
incoming patches into some directory. That would give us already some
basic data to work with and we can start to implement new features as they
are needed.

> Automating the applied/dropped status is clearly the next problem to tackle,
> but that's harder, it involves behavioral changes on the maintainers side.

What "behavioral changes"? Maintainers should react in some way or another
react to patches no matter where come from.

> (Pragmatically, providing a web interface so somebody whose job it is to do
> that, can efficiently post 'applied' messages to the list would get the job
> done without making anyone learn new tools or change the way they work.)

Web interfaces can be nice, but the bulk work should be doable by mail.
For changes in areas which have a maintainer, the mail to Linus could
include a note "forwarded to maintainer x" and Linus can still decide,
whether he applies the patch or waits for the OK from the maintainer.

> By the way, who is going to code this?  Or are we determined to make
> ourselves look like wankers once again, by putting considerably more time
> into the lkml flamewar than goes into producing working code?
>
> (Hint: I am not going to code it, nor should I since I should be working in
> the kernel.)

That's a known problem, I have no time either, but we should give anyone
interested in this some example data. This data has to come from the
kernel hackers, but patch management system is better implemented by
non-kernel hackers.

Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 30, 2002 01:39 pm, Roman Zippel wrote:
> On Wed, 30 Jan 2002, Daniel Phillips wrote:
> 
> > > I'd rather make the patchbot more intelligent, that means it analyzes 
the
> > > patch and produces a list of touched files. People can now register to 
get
> > > notified about patches, which changes areas they are interested in.
> >
> > But they can already do that, by subscribing to the respective mailing 
list
> > (obviously, the bot posts to the list as well as forwarding to the
> > maintainer) and running the mails through a filter of their choice.
> 
> What about unmaintained parts?

One or both of patches-2.4@kernel.org or patches-2.5@kernel.org

> > > In the simplest configuration nothing would change for Linus, but 
patches
> > > wouldn't get lost and people could be notified if their patch was 
applied
> > > or if it doesn't apply anymore.
> >
> > OK, it would be nice, but you wouldn't want to pile on so many features 
that
> > this never gets implemented would you?  The minimal thing that forwards 
and
> > posts patches is what we need now.  Like any other software it can be
> > improved over time.
> 
> That's what I have in mind. What we can already do now is to store
> incoming patches into some directory. That would give us already some
> basic data to work with and we can start to implement new features as they
> are needed.

Yes, mine the data.

> > Automating the applied/dropped status is clearly the next problem to 
tackle,
> > but that's harder, it involves behavioral changes on the maintainers side.
> 
> What "behavioral changes"? Maintainers should react in some way or another
> react to patches no matter where come from.

They already have their own ways of reacting.  I don't hear a lot of pleading
from maintainers for tools to help them respond to patches; most seem to be
satisfied with Mutt or whatever.  I feel sure that any attempt to force
changes to such personal practices will be met with a solid wall of
disinterest.

> > (Pragmatically, providing a web interface so somebody whose job it is to 
do
> > that, can efficiently post 'applied' messages to the list would get the 
job
> > done without making anyone learn new tools or change the way they work.)
> 
> Web interfaces can be nice, but the bulk work should be doable by mail.

Oh yes, certainly.

> For changes in areas which have a maintainer, the mail to Linus could
> include a note "forwarded to maintainer x" and Linus can still decide,
> whether he applies the patch or waits for the OK from the maintainer.

Or just cc it to lkml and don't bother Linus.  If Linus wants to know about
traffic to maintainers he can look in the mail archives (he won't).

> > By the way, who is going to code this?  Or are we determined to make
> > ourselves look like wankers once again, by putting considerably more time
> > into the lkml flamewar than goes into producing working code?
> >
> > (Hint: I am not going to code it, nor should I since I should be working 
in
> > the kernel.)
> 
> That's a known problem, I have no time either, but we should give anyone
> interested in this some example data. This data has to come from the
> kernel hackers, but patch management system is better implemented by
> non-kernel hackers.

<deleted>
That's the problem.  I have seen at least two attempted starts on a patchbot
and know of a third (Dan Quinlan was going to do something 1.5 years ago).
So at this point I want to step out of this discussion.  There is going to
be no patchbot without a coder to write it, so why spend more time talking
about it?
</deleted>

OK, on a less pessimistic note, I'll make a small effort to find a volunteer 
to code this, under advisement that it will be a thankless task (everybody 
will complain about everything) and may not even get accepted by Linus or 
anyone else (yes, and?).  So here it is:

   Wanted: a scripting person who has a clue about MTAs and wants to 
   contribute to the kernel.  Please step up to the table over here
   and sign in blood, then we will tell you what your mission is.
   Nobody will thank you for any of the work you do or reward you in
   any way, except for the right to bask in the glory and fame of
   being the one who ended the patchbot wars.  And maybe, just maybe
   get that coveted Slashdot interview.

OK. that's it, if somebody bites I'll gladly participate in a design thread, 
otherwise I think this is just going to sleep until the next bi-monthly 
patchbot flameup.

/me goes back to work

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Rasmus Andersen]

On Wed, Jan 30, 2002 at 02:28:04PM +0100, Daniel Phillips wrote:
>    Wanted: a scripting person who has a clue about MTAs and wants to 
>    contribute to the kernel.  Please step up to the table over here
>    and sign in blood, then we will tell you what your mission is.
>    Nobody will thank you for any of the work you do or reward you in
>    any way, except for the right to bask in the glory and fame of
>    being the one who ended the patchbot wars.  And maybe, just maybe
>    get that coveted Slashdot interview.
> 
> OK. that's it, if somebody bites I'll gladly participate in a design thread, 
> otherwise I think this is just going to sleep until the next bi-monthly 
> patchbot flameup.

I'll bite. I was noodling with this in the background already, so
I have some thoughts at home which I'll be happy to write up and
send to the list. Other people, notably John Weber (linuxhq)
and Patrick Mochel(? odsl) stated that they were working on
something too. As I dont do this for a living (dont mean to
imply that they are), I wouldn't want to want to be in the
way for the big boys :)

If I understand correctly, the bot would, in its basic incarnation,
accept patches (at patchbot@somewhere), stamp them with an uid,
and forward them to various places, e.g., lists, maintainers etc
and let the sumbitter know the patch uid. A mailing list archive
would then be the patch store. Basic filtering could be done by
the bot to reject non-patches etc.

The bot could also:
* Annotate patches with files touched.
* Try to apply patches and take action based on succces failure.
* Try to compile the resulting tree (based on a submitted .config)
  and take action based on the results.
* Store submissions locally and do the steps above for new
  kernel revisions, resubmtting them if appropriate.

Yes, the compile step kinda made the HW requirements go through
the roof.

I have some code already to handle some of this but typically,
I started at the wrong end and did the patch/compile stuff
first :) Ah, BTW, that is in python. I dont see a problem
with that.

Please comment but I may be offline till later this evening.

Regards,
  Rasmus

PS: Daniel have made me aware of another volunteer, Kalle
Kivimaa. I have added him to the list and could obviously
work with him.

Re: Wanted: Volunteer to code a Patchbot

[Rasmus Andersen]

On Wed, Jan 30, 2002 at 04:11:05PM +0100, Rasmus Andersen wrote:
> If I understand correctly, the bot would, in its basic incarnation,
> accept patches (at patchbot@somewhere), stamp them with an uid,
> and forward them to various places, e.g., lists, maintainers etc
> and let the sumbitter know the patch uid. A mailing list archive
> would then be the patch store. Basic filtering could be done by
> the bot to reject non-patches etc.

Somehow, I totally forgot the security disclaimer for some of
the points. Obviously, mindlessly patching a makefile and
executing it would be a Bad Idea. If no satisfying solution
to this can be found, this (execute/compile) step could be 
foregone.

Thanks to Tommy Faasen for raising this point.

Regards,
  Rasmus

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 30, 2002 04:28 pm, Rasmus Andersen wrote:
> On Wed, Jan 30, 2002 at 04:11:05PM +0100, Rasmus Andersen wrote:
> > If I understand correctly, the bot would, in its basic incarnation,
> > accept patches (at patchbot@somewhere), stamp them with an uid,
> > and forward them to various places, e.g., lists, maintainers etc
> > and let the sumbitter know the patch uid. A mailing list archive
> > would then be the patch store. Basic filtering could be done by
> > the bot to reject non-patches etc.
> 
> Somehow, I totally forgot the security disclaimer for some of
> the points. Obviously, mindlessly patching a makefile and
> executing it would be a Bad Idea. If no satisfying solution
> to this can be found, this (execute/compile) step could be 
> foregone.
> 
> Thanks to Tommy Faasen for raising this point.

I'd say, don't try to run it, just see if it applies cleanly.

Speaking of security, we can't expect Matti to take care of blocking spam
on the patch lists the way he does on lkml, so that is going to have to
be handled, or the system will fall apart.  Well, spammers are not going
to be bright enough to send correctly formed patches that apply without
rejects I hope, so maybe that is a non-problem.

The patchbot will have to understand the concept of a patch set, a
series of patches that apply in a particular order.  If it can handle
that it probably doesn't need a general way of handling inter-patch
relationships, at least to start.

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Stuart Young]

At 04:46 PM 30/01/02 +0100, Daniel Phillips wrote:
>On January 30, 2002 04:28 pm, Rasmus Andersen wrote:
> > Somehow, I totally forgot the security disclaimer for some of
> > the points. Obviously, mindlessly patching a makefile and
> > executing it would be a Bad Idea. If no satisfying solution
> > to this can be found, this (execute/compile) step could be
> > foregone.
> >
> > Thanks to Tommy Faasen for raising this point.
>
>I'd say, don't try to run it, just see if it applies cleanly.
>
>Speaking of security, we can't expect Matti to take care of blocking spam
>on the patch lists the way he does on lkml, so that is going to have to
>be handled, or the system will fall apart.  Well, spammers are not going
>to be bright enough to send correctly formed patches that apply without
>rejects I hope, so maybe that is a non-problem.

Possibly, but then it'll reply to the spammer and you'll get bounces left 
and right. Perhaps it's a simple case that the patcher submitting will have 
to have registered the email address before submitting their patch. Only 
needs to be done once (not every time a patch is submitted, that's mad!), 
and weeds out the noise.


Stuart Young - sgy@amc.com.au
(aka Cefiar) - cefiar1@optushome.com.au

[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 31, 2002 01:49 am, Stuart Young wrote:
> At 04:46 PM 30/01/02 +0100, Daniel Phillips wrote:
> >On January 30, 2002 04:28 pm, Rasmus Andersen wrote:
> > > Somehow, I totally forgot the security disclaimer for some of
> > > the points. Obviously, mindlessly patching a makefile and
> > > executing it would be a Bad Idea. If no satisfying solution
> > > to this can be found, this (execute/compile) step could be
> > > foregone.
> > >
> > > Thanks to Tommy Faasen for raising this point.
> >
> >I'd say, don't try to run it, just see if it applies cleanly.
> >
> >Speaking of security, we can't expect Matti to take care of blocking spam
> >on the patch lists the way he does on lkml, so that is going to have to
> >be handled, or the system will fall apart.  Well, spammers are not going
> >to be bright enough to send correctly formed patches that apply without
> >rejects I hope, so maybe that is a non-problem.
> 
> Possibly, but then it'll reply to the spammer and you'll get bounces left 
> and right. Perhaps it's a simple case that the patcher submitting will have 
> to have registered the email address before submitting their patch. Only 
> needs to be done once (not every time a patch is submitted, that's mad!), 
> and weeds out the noise.

Yes, that's a point for discussion.  Certainly, a patchbot list like 
patches-2.5-maintainer should require registration, and in fact, registration 
for this list will be by invitation.  It's not so clear what the policy 
should be on the patches-2.5 list.  Openness is a nice thing to be able to 
boast about.  Maybe the thing to do is try it open, and see how it works out.

We also have to worry about malicious spamming of the patch list.  I've heard 
this happened to kuro5hin's story submission queue - there is no accounting 
for all the forms of insect life out there.

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Stuart Young]

At 02:26 AM 31/01/02 +0100, Daniel Phillips wrote:
>On January 31, 2002 01:49 am, Stuart Young wrote:
> > Possibly, but then it'll reply to the spammer and you'll get bounces left
> > and right. Perhaps it's a simple case that the patcher submitting will 
> have
> > to have registered the email address before submitting their patch. Only
> > needs to be done once (not every time a patch is submitted, that's mad!),
> > and weeds out the noise.
>
>Yes, that's a point for discussion.  Certainly, a patchbot list like
>patches-2.5-maintainer should require registration, and in fact, registration
>for this list will be by invitation.  It's not so clear what the policy
>should be on the patches-2.5 list.  Openness is a nice thing to be able to
>boast about.  Maybe the thing to do is try it open, and see how it works out.

True. But if it comes to it, a once off authentication to 'allow' an e-mail 
address weeds out a hell of a lot of spambots.

>We also have to worry about malicious spamming of the patch list.  I've heard
>this happened to kuro5hin's story submission queue - there is no accounting
>for all the forms of insect life out there.

Malicious spamming will happen no matter what you do, unless you vet the 
subscriptions manually.


Stuart Young - sgy@amc.com.au
(aka Cefiar) - cefiar1@optushome.com.au

[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]

Re: Wanted: Volunteer to code a Patchbot

[Rik van Riel]

On Thu, 31 Jan 2002, Stuart Young wrote:

> Possibly, but then it'll reply to the spammer and you'll get bounces left
> and right. Perhaps it's a simple case that the patcher submitting will have
> to have registered the email address before submitting their patch. Only
> needs to be done once (not every time a patch is submitted, that's mad!),
> and weeds out the noise.

--------------------------------------------------------------
This is the patchbot auto-reply.

You tried to send me a patch (attached below) but I don't
know you.  To confirm that you exist (and aren't a spammer)
please reply to this message.

After receiving your reply your queued patches will be
published.
--------------------------------------------------------------

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Wanted: Volunteer to code a Patchbot

[Patrick Mauritz]

On Thu, Jan 31, 2002 at 11:51:53AM -0200, Rik van Riel wrote:
> --------------------------------------------------------------
> This is the patchbot auto-reply.
> 
> You tried to send me a patch (attached below) but I don't
> know you.  To confirm that you exist (and aren't a spammer)
> please reply to this message.
> 
> After receiving your reply your queued patches will be
> published.
> --------------------------------------------------------------

ok, so then I look for some open relay and the email address of my
neighbour I dislike and send some hundred mails with his address in the 
From: field - lotsa fun...

patrick mauritz
-- 
,------------------------------------------------------------------------.
>   In the Beginning there was nothing, which exploded - Yeah right...   <
|------------------------------------------------------------------------|
>                      plex86 NOW! | www.plex86.org                      <
`------------------------------------------------------------------------'
         Your right to swing your fist ends where my nose begins

Re: Wanted: Volunteer to code a Patchbot

[Jan Harkes]

On Thu, Jan 31, 2002 at 04:29:20PM +0100, Patrick Mauritz wrote:
> On Thu, Jan 31, 2002 at 11:51:53AM -0200, Rik van Riel wrote:
> > --------------------------------------------------------------
> > This is the patchbot auto-reply.
> > 
> > You tried to send me a patch (attached below) but I don't
> > know you.  To confirm that you exist (and aren't a spammer)
> > please reply to this message.
> > 
> > After receiving your reply your queued patches will be
> > published.
> > --------------------------------------------------------------
> 
> ok, so then I look for some open relay and the email address of my
> neighbour I dislike and send some hundred mails with his address in the 
> From: field - lotsa fun...

Drop anything that is not text/plain and doesn't contain

diff -urN [--exclude-from=dontdiff]
--- yyy
+++ zzz

Maybe bounce when the diff includes any files that shouldn't be part of
the diff (http://www.moses.uklinux.net/patches/dontdiff) with a nice
message to get that file and add --exclude-from=dontdiff or explain that
patches can get dropped silently when they are not in unidiff format,
include generated files, or have any type of non text/plain attachment.

And whenever spam starts 'adhering' to the suggested format of linux
kernel patches we'll get an interesting kernel indeed. Where are the
many (human) eyes in this picture anyways. Do people get to vote
for/veto patches in the patchbot queue?

Evil thought, patchbot would turn into some form of a 'slashdot' with
karma whores and petrified goats and such. Hmm, maybe we should keep
things the way they are right now.

Jan

Re: Wanted: Volunteer to code a Patchbot

[Horst von Brand]

Stuart Young <sgy@amc.com.au> said:

[...]

> Possibly, but then it'll reply to the spammer and you'll get bounces left 
> and right. Perhaps it's a simple case that the patcher submitting will have 
> to have registered the email address before submitting their patch. Only 
> needs to be done once (not every time a patch is submitted, that's mad!), 
> and weeds out the noise.

And then lkml will be swamped with questions as to why the automated patch
system doesn't work, or it will just not be used at all because it is more
work than just firing off a patch at lkml.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 31, 2002 11:05 pm, Horst von Brand wrote:
> Stuart Young <sgy@amc.com.au> said:
> 
> [...]
> 
> > Possibly, but then it'll reply to the spammer and you'll get bounces left 
> > and right. Perhaps it's a simple case that the patcher submitting will
> > have to have registered the email address before submitting their patch. 
> > Only needs to be done once (not every time a patch is submitted, that's 
> > mad!), and weeds out the noise.
> 
> And then lkml will be swamped with questions as to why the automated patch
> system doesn't work, or it will just not be used at all because it is more
> work than just firing off a patch at lkml.

The plan is to have both open and registered-users-only patchbots.  The 
second kind is the kind to which maintainers themselves submit to, so the 
forwarded stream of patches is guaranteed to come from trustworthy sources.  
Maintainers themselves can configure their own patchbots to be open or closed 
as they see fit.  In essense, neither submitters not maintainers will see any 
change at all in their procedures, except for the address to which they send 
the patch.[1]

There will be a very significant change in the results of this process from 
the submitter's point of view, since everybody will know where to look to see 
what patches have been submitted, to whom, when, why etc.

There are a lot of things we can do with the patches once they're all sitting 
in the patchbot's database, including tracking the state - applied, rejected, 
being revised, etc.  That's for later, the task at hand is simply to clarify 
and streamline the lines of communication between submitters and maintainers.

[1] Submitters *may* chose to fill in a few lines of metadata in their patch 
to specify, for example, a one-line description which is different from the 
email subject, or that they are not interested in confirmation.  Such 
metadata is not required - the patchbots will accept patches in exactly the 
format we are used to.

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Stuart Young]

At 11:51 AM 31/01/02 -0200, Rik van Riel wrote:
>On Thu, 31 Jan 2002, Stuart Young wrote:
>
>--------------------------------------------------------------
>This is the patchbot auto-reply.
>
>You tried to send me a patch (attached below) but I don't
>know you.  To confirm that you exist (and aren't a spammer)
>please reply to this message.
>
>After receiving your reply your queued patches will be
>published.
>--------------------------------------------------------------

Beautiful. Just beautiful. *grin*

Just hope the spammers don't catch on and start sending replies.


Stuart Young - sgy@amc.com.au
(aka Cefiar) - cefiar1@optushome.com.au

[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]

Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

(reposted to fix the word wrap)

On January 30, 2002 01:39 pm, Roman Zippel wrote:
> On Wed, 30 Jan 2002, Daniel Phillips wrote:
> 
> > > I'd rather make the patchbot more intelligent, that means it analyzes the
> > > patch and produces a list of touched files. People can now register to get
> > > notified about patches, which changes areas they are interested in.
> >
> > But they can already do that, by subscribing to the respective mailing list
> > (obviously, the bot posts to the list as well as forwarding to the
> > maintainer) and running the mails through a filter of their choice.
> 
> What about unmaintained parts?

One or both of patches-2.4@kernel.org or patches-2.5@kernel.org

> > > In the simplest configuration nothing would change for Linus, but patches
> > > wouldn't get lost and people could be notified if their patch was applied
> > > or if it doesn't apply anymore.
> >
> > OK, it would be nice, but you wouldn't want to pile on so many features that
> > this never gets implemented would you?  The minimal thing that forwards and
> > posts patches is what we need now.  Like any other software it can be
> > improved over time.
> 
> That's what I have in mind. What we can already do now is to store
> incoming patches into some directory. That would give us already some
> basic data to work with and we can start to implement new features as they
> are needed.

Yes, mine the data.

> > Automating the applied/dropped status is clearly the next problem to tackle,
> > but that's harder, it involves behavioral changes on the maintainers side.
> 
> What "behavioral changes"? Maintainers should react in some way or another
> react to patches no matter where come from.

They already have their own ways of reacting.  I don't hear a lot of pleading
from maintainers for tools to help them respond to patches; most seem to be
satisfied with Mutt or whatever.  I feel sure that any attempt to force
changes to such personal practices will be met with a solid wall of
disinterest.

> > (Pragmatically, providing a web interface so somebody whose job it is to do
> > that, can efficiently post 'applied' messages to the list would get the job
> > done without making anyone learn new tools or change the way they work.)
> 
> Web interfaces can be nice, but the bulk work should be doable by mail.

Oh yes, certainly.

> For changes in areas which have a maintainer, the mail to Linus could
> include a note "forwarded to maintainer x" and Linus can still decide,
> whether he applies the patch or waits for the OK from the maintainer.

Or just cc it to lkml and don't bother Linus.  If Linus wants to know about
traffic to maintainers he can look in the mail archives (he won't).

> > By the way, who is going to code this?  Or are we determined to make
> > ourselves look like wankers once again, by putting considerably more time
> > into the lkml flamewar than goes into producing working code?
> >
> > (Hint: I am not going to code it, nor should I since I should be working in
> > the kernel.)
> 
> That's a known problem, I have no time either, but we should give anyone
> interested in this some example data. This data has to come from the
> kernel hackers, but patch management system is better implemented by
> non-kernel hackers.

<deleted>
That's the problem.  I have seen at least two attempted starts on a patchbot
and know of a third (Dan Quinlan was going to do something 1.5 years ago).
So at this point I want to step out of this discussion.  There is going to
be no patchbot without a coder to write it, so why spend more time talking
about it?
</deleted>

OK, on a less pessimistic note, I'll make a small effort to find a volunteer 
to code this, under advisement that it will be a thankless task (everybody 
will complain about everything) and may not even get accepted by Linus or 
anyone else (yes, and?).  So here it is:

   Wanted: a scripting person who has a clue about MTAs and wants to 
   contribute to the kernel.  Please step up to the table over here
   and sign in blood, then we will tell you what your mission is.
   Nobody will thank you for any of the work you do or reward you in
   any way, except for the right to bask in the glory and fame of
   being the one who ended the patchbot wars.  And maybe, just maybe
   get that coveted Slashdot interview.

OK. that's it, if somebody bites I'll gladly participate in a design thread, 
otherwise I think this is just going to sleep until the next bi-monthly 
patchbot flameup.

/me goes back to work

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Wed, Jan 30, 2002 at 02:45:59PM +0100, Daniel Phillips wrote:

> (reposted to fix the word wrap)
> 
> On January 30, 2002 01:39 pm, Roman Zippel wrote:
> > On Wed, 30 Jan 2002, Daniel Phillips wrote:
> > 
> > > > I'd rather make the patchbot more intelligent, that means it
> > > > analyzes the patch and produces a list of touched
> > > > files. People can now register to get notified about patches,
> > > > which changes areas they are interested in.
> > >
> > > But they can already do that, by subscribing to the respective
> > > mailing list (obviously, the bot posts to the list as well as
> > > forwarding to the maintainer) and running the mails through a
> > > filter of their choice.

I realise I'm jumping in half-way through a thread, but people
interested in doing this might want to look at how lsdiff and
filterdiff can help.

Tim.
</plug>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Wanted: Volunteer to code a Patchbot

[Patrick Mochel]

Hi everyone. 

> <deleted>
> That's the problem.  I have seen at least two attempted starts on a patchbot
> and know of a third (Dan Quinlan was going to do something 1.5 years ago).
> So at this point I want to step out of this discussion.  There is going to
> be no patchbot without a coder to write it, so why spend more time talking
> about it?
> </deleted>
> 
> OK, on a less pessimistic note, I'll make a small effort to find a volunteer 
> to code this, under advisement that it will be a thankless task (everybody 
> will complain about everything) and may not even get accepted by Linus or 
> anyone else (yes, and?).  So here it is:
> 
>    Wanted: a scripting person who has a clue about MTAs and wants to 
>    contribute to the kernel.  Please step up to the table over here
>    and sign in blood, then we will tell you what your mission is.
>    Nobody will thank you for any of the work you do or reward you in
>    any way, except for the right to bask in the glory and fame of
>    being the one who ended the patchbot wars.  And maybe, just maybe
>    get that coveted Slashdot interview.
> 
> OK. that's it, if somebody bites I'll gladly participate in a design thread, 
> otherwise I think this is just going to sleep until the next bi-monthly 
> patchbot flameup.

As promised yesterday, a Sourceforge project has been started for a Linux 
Kernel Patch Management System (lk-pms). The page is at:

http://sourceforge.net/projects/lk-pms/

A mailing has been set up for discussion of the development of the 
project. We would like to move the discussion off of linux-kernel onto 
this new mailing list and begin to formalize the concept and the design.

We (OSDL) are volunteering resources for the development of the project: 
developer time, hardware, and bandwidth. We are willing to host it on our 
servers, and would like to eventually integrate such a system with our 
automated test system (STP). Any and all feedback is welcome, preferably 
on the list, though private mail is also welcome. 


Thanks,

	-pat

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On January 30, 2002 06:46 pm, Patrick Mochel wrote:
> As promised yesterday, a Sourceforge project has been started for a Linux 
> Kernel Patch Management System (lk-pms). The page is at:
> 
> http://sourceforge.net/projects/lk-pms/

OK, we have competing patchbot projects:

   http://killeri.net/cgi-bin/alias/ezmlm-cgi

I don't see a single thing wrong with that, it gives us twice as many chances 
for one to succeed.

> A mailing has been set up for discussion of the development of the 
> project. We would like to move the discussion off of linux-kernel onto 
> this new mailing list and begin to formalize the concept and the design.
> 
> We (OSDL) are volunteering resources for the development of the project: 
> developer time, hardware, and bandwidth. We are willing to host it on our 
> servers, and would like to eventually integrate such a system with our 
> automated test system (STP). Any and all feedback is welcome, preferably 
> on the list, though private mail is also welcome. 

Ah, yum, we are jealous.

But not very ;-)

May the best bot win...

-- 
Daniel

Re: Wanted: Volunteer to code a Patchbot

[Peter C. Norton]

BTW, in the interest of not re-inventing the wheel, and I'm sorry if this
has been mentioned already in this thread, but for confirmations,
whitelist/blacklist stuff for the patchbots take a look at tmda, at
http://tmda.sourceforge.net.

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

Re: Wanted: Volunteer to code a Patchbot

[Daniel Phillips]

On February 3, 2002 07:54 pm, Peter C. Norton wrote:
> BTW, in the interest of not re-inventing the wheel, and I'm sorry if this
> has been mentioned already in this thread, but for confirmations,
> whitelist/blacklist stuff for the patchbots take a look at tmda, at
> http://tmda.sourceforge.net.

Thanks for this, but whitelist/blacklist is just one aspect of the patchbot, 
and far from the most important aspect.  I think tmda might have a little 
trouble validating a patch against a kernel tree, for example

In Python the white/blacklist handling is trivial anyway.  A workable 
confirmation feature was coded in a couple of hours by the guys (Rasmus and 
Kalle) working on the bot, and it does exactly what we want it to.  Progress 
marches on, Python rocks.  (So do Rasmus and Kalle.)

-- 
Daniel