Re: Linux 2.6.21

[Kyle Moffett <mrmacman_g4@mac.com>]

It might not be bad to write up an email-based BTS-alike bug-tracking  
system just for the Linux kernel.  It should probably even be  
implemented 100% via email at first, with a web-based status viewer  
as a later add-on.  Here's a possible email format:

[kbugger: action1 arg1 arg2 ..., action2 arg1 arg2 ...]

Make it almost totally message-id and thread based, and make it an  
implicit part of LKML (IE: subscribe the kbugger program to LKML).   
People who are flagged "admin" may ban/unban users and make certain  
large-scale changes.  Supported actions:

create, create-parent, create-thread:
   Create a new bug associated with this message.
   The arguments specify the title.
   This would automatically happen for new threads with titles like  
"[BUG] foo: It's broken"

merge:
   Merges the current bug and/or email thread into an existing bug.
   The arguments are a list of bug numbers and/or message-IDs to  
merge together with this one.

prune, prune-parent, prune-thread:
   Prunes a given thread from the current bug.
   Optional argument specifies a referential message-ID

settitle:
   Change the title of the current bug

fixed, broken:
   Mark the bug as fixed or broken in a particular version/configuration
   Arguments are used as opaque strings representing configurations  
where it is known to be fixed or broken.  For example [kbugger: fixed  
2.6.16 2.6.20-x86, broken 2.6.20-ppc] would just store the list of  
strings and statuses.  If the bug was auto-created with a title like  
"[BUG ppc] foo: It's broken" or "[BUG 2.6.20] bar: I dunno", then the  
argument to the [BUG] title portion will be auto-passed to [kbugger:  
broken].

status:
   Get a brief status report on the current bug.

info:
   Get a detailed status report on the current bug.

history:
   Get detailed information about the history of the current bug.   
This only sends the reply to the author.

stop:
   Stop parsing the rest of this email.  Useful when teaching  
somebody about kbugger commands via an email sent to kbugger itself.

The results of the kbugger statements in an email will be sent as a  
reply to the original message and "To:" the original sender, "CC:"- 
ing the targets of the message, so if the original [kbugger: create]  
post went to LKML then the reply will go there as well for people to  
read and for it to be archived by kbugger as part of the status  
history of that bug.  All emails it receives will be autoparsed for  
commands, however it should be coded to ignore all text in emailed  
patches, and it should support the [kbugger: stop] command to halt  
parsing for cases where you need to send plain kbugger commands via  
email.

If somebody was feeling unusually brave they might add some  
keyword<=>author bayesian tracking so that it could automatically  
discover the keywords in emails that particular authors reply to and  
helpfully forward a kbugger info email to that person with a link to  
the archives for the original thread.  If somebody didn't want to  
receive such info messages they could click a link or send a  
[kbugger: no-auto-forward] command to blacklist themselves from  
receiving automatic forwards ([kbugger: auto-forward] to re-enable).   
Maybe even [kbugger: not-for-me ...] and [kbugger: for-me] commands  
which take bug numbers and message-IDs to tune the keyword lists.

I may try working on something like that this week if I get the time.

Cheers,
Kyle Moffett