Tom Lane wrote:
> For the past couple of weeks I've been dealing with both Bruce's queue
> and the one at
> 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.
In response to
pgsql-www by date
|Next:||From: Bruce Momjian||Date: 2008-04-02 23:23:58|
|Subject: Advertizing email footers|
|Previous:||From: Tom Lane||Date: 2008-04-02 19:21:02|
|Subject: Re: Patch queue -> wiki (was varadic patch) |
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-04-02 20:29:31|
|Subject: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong |
|Previous:||From: Andrew Dunstan||Date: 2008-04-02 19:41:10|
|Subject: Re: notify with payload (pgkill, notify)|