Patch queue -> wiki (was varadic patch) - Mailing list pgsql-hackers

From Greg Smith
Subject Patch queue -> wiki (was varadic patch)
Date
Msg-id Pine.GSO.4.64.0804021233380.20786@westnet.com
Whole thread Raw
In response to Re: varadic patch  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Patch queue -> wiki (was varadic patch)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2 Apr 2008, Bruce Momjian wrote:

> The new permanent ones are permanent against mailbox movement, and in 
> fact the comments and thread merging also travels with the email.

The "someone replied to your comment" links in e-messages I've been 
getting the last few days have all been working, which is a first.  The 
configuration you're running right now I'd consider the first candidate to 
be a "stable" version, so thumbs up from me for reaching that point.

It's clear to me only now that you can think of the patch queue as being a 
list with this structure:

1) Patch name (defaults to the subject of the first message)
2) List of messages related to that patch
3) List of comments
4) Status
5) Assigned reviewers

Bruce's toolchain converts an mbox of messages to generate the first two, 
then has a web interface to allow adding the third.  Right now the message 
list is internally consistant but not useful in the long term (doesn't 
have links to the archives, just this temporary page).  Until the "search 
for message ID" feature is added to the archives I don't know that this 
situation can be improved.

Those hacking on tools to convert Bruce's currently preferred working form 
(that revolves around mbox files) into something else that's web oriented 
are stuck with considering how all the above information is going to be 
handled before everybody will be satisfied.  I can see how a script that 
converts the current pages into wiki markup, with placeholders where 
someone can manually update the comments to summarize those on the page, 
would be helpful.  That basically creates an easier to read "Queue 
summary" like Stephan was doing for 8.3--that included items 1,4,5 from 
the above.  But that's a one-way operation that doesn't really help with 
the commenting situation, and it's inevitably going to lag behind the 
mailbox-centered queue unless it's made fully automatic.  I can't think of 
anything better that doesn't require building some sort of database that 
holds all this information and drives page generation.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Matthew Wetmore
Date:
Subject: Visa CISP PCI compliance needs SHA1?
Next
From: Andrew Dunstan
Date:
Subject: Re: US VISA CISP PCI comp. needs SHA1