Patch queue -> wiki (was varadic patch)

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Patch queue -> wiki (was varadic patch)
Date: 2008-04-02 17:58:03
Message-ID: Pine.GSO.4.64.0804021233380.20786@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-04-02 18:00:42 Re: US VISA CISP PCI comp. needs SHA1
Previous Message Matthew Wetmore 2008-04-02 17:52:21 Visa CISP PCI compliance needs SHA1?

Browse pgsql-www by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2008-04-02 19:05:16 Re: CVS rsync service is dropping some files
Previous Message Peter Eisentraut 2008-04-02 16:21:04 CVS rsync service is dropping some files