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