Re: Commit fest queue - Mailing list pgsql-hackers

> Yup, that is *exactly* the point.  A wiki page is a zero-setup-cost,
> flexible way of experimenting with tracking commit-fest issues.
> A year from now, we might have enough experience to decide that some
> more-rigidly-structured tool will do what we need, but we don't have
> it today.  We spent enough time fighting the limitations of Bruce's
> mhonarc page that we ought to be wary of adopting some other tool that
> wants you to do things its way.

In case you don't recognize my name/email address I am just someone  
who has been lurking on hackers for several years now.  I have been  
following this thread closely and I thought it might be useful for  
someone to try to summarize what it seems like people need so everyone  
can see if they are on the same page. After stating each problem I  
will also summarize proposed solutions and introduce a few of my own,  
just to see what people think.  Also I have been a web developer for  
the 7 years so I may be able to help out with this, as long as the  
time span is sufficiently long.  Please feel free to correct anything  
below (as if I have to say that).  Remember I am not trying to push  
any idea here, I am just trying to summarize everyone else's ideas and  
humbly propose a few ideas that might help.

It's clear that you want to keep the email list as the primary means  
of communication.  So that obviously has to stay.  The web archives  
should stay the primary means of referencing past discussion.

Problem #1: The current archive system breaks threads across monthly  
boundaries.
Solution 1A: Find other "off the shelf" software that does this better.
Solution 1B: Write some custom software to do this.  Can you set up  
hooks into the mail server so that a script could be run each time a  
new email is accepted?  Given the full message headers and body, what  
is the algorithm for linking methods into threads?  Given the right  
answers to those two questions and this might be a fairly simple task.

Problem #2: When people are looking for something to do we need a list  
of all pending issues that can be easily searched.  Ideally the  
maintenance of this list will be as low as possible.
Solution 2: Create a custom tracker.  The above email and others seem  
to indicate nothing off the shelf will do.  Can a hook be set up into  
the mail server so that incoming emails can not only be read and  
indexed but also altered with a script?  Each new thread from patches  
could automatically create a tracker item.  At the bottom of each  
message a link could be added to the tracker item for that thread.   
Then going from email message (in your MUA or the web archives) to the  
tracker would be quick and easy.  Each email from hackers could have a  
link at the bottom to create a tracker item for it.  So patches  
threads get automatic tracker items.  Hackers threads can be added  
manually.

The tracker page for each message would include whatever metadata was  
needed.  For instance: has this tracker item been processed yet?  Is  
it a bug or a feature request or just a request for information or a  
fix to infrastructure?  Is there a reviewer for the patch?  Which fest  
does it belong to?  Or any other metadata you might want to add to the  
item.  Also on the page would be the thread that started the item.   
Initially it would show only subjects.  Clicking on a subject will  
show the body of the message inline with the thread. Clicking it again  
will collapse it again.  There will be a reply link for each message.   
If you reply via the web site it will simply send a message to the  
mail server just as it would if you had replies within your MUA.  That  
way there is no difference between replying from within the tracker  
and replying from within your normal mail client.  But you can still  
use either and the communication doesn't get scattered all over the  
place.  There would also be an option to let you choose another  
tracker item to merge with the current one so that relevant threads  
can be aggregated into the same tracker item.

At this point you could have a page that lists all unassigned tracker  
items so that someone looking for some work to do could quickly scan a  
short easy to read list and pick something.

Problem #3: When a new patch creator posts a new patch they need  
feedback quickly so they know at least that they did the right thing  
and someone is aware of the patch.
Solution 3: The tracker has  a list of all new threads that haven't  
been looked at.  Someone can then go through the list of unprocessed  
items and see if it has a patch. If it does he can flag that item as a  
patch submission and it will immediately show up on the list for patch  
reviewers to look through.  It can also be assigned right there to a  
specific fest but will default to the soonest one.  Once it is flagged  
an email will automatically go out telling them their patch is pending  
review.

Problem #4: Patches may or may not, on rare occasions, fall through  
the cracks.  :)
Solution 4: Now all new threads will show up in the new items list.   
If no one ever goes through the list they will still fall through the  
cracks.  But at least there will be a list of items that need to be  
dealt with.  It could also sort them by when they were submitted and  
even send out a notification if there are items older than x days/ 
weeks/months.

Problem #5: Sometimes people want to be notified when an event happens.
Solutions 5: Once we have the tracker going it is trivial to take any  
even within the system,  and send notifications to those who want it  
and only those who want it.  These notifications could contain as much  
or as little info as you like.

All in all the intention here is to build a light wrapper around the  
email system that adds some needed functions but doesn't mess up  
anything that is currently working.  Being that I am not actually  
involved in the process it's very likely that there is one or several  
fatal flaws in this proposal, but I have done my best to address  
everyone's needs.

Hope this is useful,

Rick