Re: Commit fest queue

Gregory Stark <stark(at)enterprisedb(dot)com> 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