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
-
