Gregory Stark <[EMAIL PROTECTED]> writes: > Personally I don't think we *know* what we want to do and that's why the wiki > is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost, flexible way of experimenting with tracking commit-fest issues. A year from now, we might have enough experience to decide that some more-rigidly-structured tool will do what we need, but we don't have it today. We spent enough time fighting the limitations of Bruce's mhonarc page that we ought to be wary of adopting some other tool that wants you to do things its way. Perhaps an example will help make the point. Throughout this past fest I was desperately wishing for a way to group and label related issues --- we had a pile of items focused around index AM API questions, and another pile focused around mapping problems (FSM/DSM/Visibility map/etc), and being able to put those together would have made it a lot clearer what needed to be looked at together with what else. On a wiki page it'd have been no trouble at all to create ad-hoc sub-headings and sort the individual items into whatever grouping and ordering made sense (in fact, Alvaro did some of that on his own). It was basically impossible to do any such thing with Bruce's mhonarc page, though he did kluge up some ways to partially address the issue by merging threads. The bug trackers I've dealt with haven't got much flexibility in this respect either --- the sorts of global views you can get are entirely determined by the tool. I'm fairly certain that a tracker designed around the assumption that different entries are essentially independent isn't going to be very helpful. 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