Greg Smith <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
