Re: Commit fest queue

On Apr 11, 2008, at 9:30 AM, Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Personally I don't think we *know* what we want to do and that's
>> why the wiki
>> is a good interim tool.
>
> 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.
>
> Perhaps an example will help make the point. Throughout this past
> fest
> I was desperately wishing for a way to group and label related issues
> --- we had a pile of items focused around index AM API questions, and
> another pile focused around mapping problems (FSM/DSM/Visibility
> map/etc), and being able to put those together would have made it a
> lot clearer what needed to be looked at together with what else.
> On a wiki page it'd have been no trouble at all to create ad-hoc
> sub-headings and sort the individual items into whatever grouping and
> ordering made sense (in fact, Alvaro did some of that on his own).
> It was basically impossible to do any such thing with Bruce's mhonarc
> page, though he did kluge up some ways to partially address the issue
> by merging threads. The bug trackers I've dealt with haven't got much
> flexibility in this respect either --- the sorts of global views you
> can
> get are entirely determined by the tool. I'm fairly certain that a
> tracker designed around the assumption that different entries are
> essentially independent isn't going to be very helpful.

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. I have however followed the thread
closely (and other similar threads over the past few years) and tried
my best to address everyone's concerns. I have also used all of the
other tracking tools (wiki, bruce's pages, etc) for the purpose of
keeping myself informed as to what features are being worked on /
committed to future releases. In the end, I think the structure of a
system like this will end up being much, much easier to maintain than
a more general purpose tool such as a wiki, if we can get it right.

Hope this is useful,

Rick