Re: Commit fest queue - Mailing list pgsql-hackers

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