I'm just an observer here, but I thought I'd present an idea. Feel free to
tell me I'm nuts if you don't like it.
It seems to me that there are two main concerns in this area on discussion:
1. How to create a list of patches/review items/etc without adding a
significant amount of noise to this list of patches/review items/etc.
>From the discussion so far, it seems obvious that this part needs to be done
manually. Any automated system would not be smart enough to accurately pick
the right messages. It would either require the user to remove many non-list
items or would require the user to manually enter items.
2. How to make this newly generated list available and easy to work with for
those wishing to review. This method would need to (a) remain up to date,
(b) easily modified or rearranged, (c) has a significant amount of
information about the patch (with attachments), and (d) make sure comments
or changes to the item's status are sent back to the mailing list.
This last step is proving most difficult. I'll quickly outline a few of the
approaches and then present what I think might be what is needed.
The original solution had Bruce generating the list by working through his
mailbox and marking down the important e-mails. I suspect that less than 50%
of these actually ended up on his list. (please correct me if I'm wrong)
This was awkward for everyone else because there was very little visibility
of this list, so it was difficult for others to see what they could help
with. (concern #2)
The next, and current, solution involves someone saving the list they
generate to a wiki page. This adds work for that person (Bruce, I think) to
put it up in a wiki-style format, but does improve visibility of the list.
It ends up being a bit more work, but allows more than one person to help,
thereby speeding up the process. It's still not perfect, as updating is
manual (2a), links back to messages don't always have enough info (2c) and
comments aren't sent back to the list (2d). That being said - it is a big
improvement as visibility is much better.
The third proposed idea is to use some sort of tracker. Ideas proposed were
to (*) add everything from the mailing list to the tracker and close noise
items manually or (**) manually add the specific items of interest. These
two approaches have concerns with causing the data to be in yet another
location **, with missing patches in the process **, or with causing a
massive amount of maintenance work *.
>Proposed Idea<
It sounds like you need an e-mail controlled list. For example, setup a
filter that would create a tracker entry in response to a specific
keyword/keyphrase in an e-mail. The tracker entry could then be modified
entirely through a set of e-mailed commands.
For example, a tracker could be setup that would create a *hidden* tracker
item for each e-mail thread, but only un-hide the tracker item when an
e-mail in the thread contains "tr:add" or other such suitable command. From
then on, the tracker item would continue to gather e-mail and updates as
normal. Those wishing to use the web based interface would be free to do so.
Any changes {comments,status updates,attachments} would be sent back to the
e-mail thread.
This would allow the user to easily bring up a list of open patches, or
whatever other list they might want.
There would, of course, need to be a few additional commands accepted via
e-mail, such as commands to change the status, mark tracker items as the
same, and mark tracker items as addressed, or mark items as related. Also,
there should be some limits as to who (e-mail address) is allowed to modify
the tracker items.
Let's see how such a system addressed the 2 concerns listed at the start of
this mail.
1. Items would not be automatically added to the tracker (at least not
visibly), so noise would not be a problem. It would still require someone to
fire off an e-mail to add (un-hide) an e-mail thread in the tracker. This
does not increase the work required in creating the list, so things are good
here. Such an e-mail could also include Bruce's usual 'patch has been added
to the list' message, so this would be very visible and easily trackable.
2a. The tracker would continue to process new messages from the list, so it
would not fall out of date. (unless a new e-mail thread was started - but
this is no worse than you have today)
2b. The list could be easily modified by a large number of people via e-mail
or through the web interface (while keeping the e-mail list informed).
2c. The tracker items added would have the entire thread history all in one
spot, so it is easy to review.
2d. The tracker would send comments (not just comment notifications) back to
the list so information would not be missing from the e-mail archives.
So, that's the idea. Thoughts? (Or dare I ask!)
