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

Greg Smith <gsmith@gregsmith.com> writes:
> 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.

This seems to be ignoring the possibility of those involved with the
patch queue simply manually editing the wiki page.

For the past couple of weeks I've been dealing with both Bruce's queue
and the one at
http://wiki.postgresql.org/wiki/CommitFest:March
and frankly I find the latter a *whole* lot more satisfactory, despite
the fact that it's got exactly zero custom tooling or infrastructure
behind it.  It doesn't have artificial constraints on page organization;
I can update it as soon as I've done something rather than waiting
around for Bruce to do so; and there's an automatically maintained
history of changes.  Bruce has put a whole lot of man-hours into
getting his page to do a few of the things we could do for free with
the wiki page, but it's still got a long way to go.

Now it would certainly be nice if there were some tools that would
assist with dumping URLs for newly-arrived messages into the wiki page.
Perhaps some of the pgsql-www crowd can think about how to do that.
But even if we had to do that entirely by hand, I'd rather go with the
wiki page.

At some point it might be worth building the sort of heavy-duty
infrastructure for the patch queue that you have in mind here.
I don't think we need it yet, though, and I definitely don't think
we understand our requirements well enough yet to start designing
it.  One of the reasons I like the wiki approach is exactly that
there's such a low barrier to getting started with it.
        regards, tom lane