Re: Linux 2.6.21

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux