Re: Commit fest queue

"Tom Dunstan" <pgsql(at)tomd(dot)cc> writes:

> The reason a tracker is better imo than a wiki is that a wiki still
> needs someone to maintain an index page (or multiple index pages for
> different queues), so there's still an opportunity for something to
> fall through.

For the umpteenth time bug trackers *still* require someone to maintain the
list. It's more structured which is great if it matches the structure you
want, but it still requires someone to go open bugs when a bug is reported by
email, close bogus bugs or bugs fixed via collateral damage, update bugs when
discussions happen on the list about them, etc.

Imagining that bug trackers are all automatic and don't require any work or
impose any restrictions is missing the whole point. The whole benefit they
provide is precisely that they make that process systematic. They don't do it
for you.

I've seen no discussion about the structure the various bug trackers use and
which would match better with our processes. *That* would be the only useful
discussion to be having. What attributes do you think patch submissions have,
what is the workflow which sets which attributes at which time, who is
involved in which step of this workflow? Etc.

Proposing specific tools without a consensus on what that process is putting
the cart before the horse. You pick the tools to fit what you want to do. We
haven't decided what we want to do yet.

Personally I don't think we *know* what we want to do and that's why the wiki
is a good interim tool. We'll see what info we need there and who needs to
fill it in and find out what tool will fit our needs.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!