> Well, you need to get some agreement on what the bug tracker > is for. Is > it: > > a) a front-end to deal with complaints and bugs people have. > Is it something you expect end users to look at? This is how > Debian uses its bug-tracker, to make sure issues people bring > up don't get lost. You can always close the bug if it isn't a > real bug.
If we ask to take all complains, questions and bugs through a "bugtracker", then it's not a bugtracker. It's more of an "anything goes tracker", that usually ends up being a web based forum (with mail links) without all the features that makes a web based forum at all usable. (And I still think mailinglists are a lot more usable then a web based forum that *does* have a lot of functionality) This is what IMHO you see with a *lot* of OSS projects that use bugzilla or whatever. A bazillion bugs that aren't bugs but discussions or questions etc. Can't speak about the debian example, haven't checked theirs out. We already have our mailinglist archives dealing with this. I really can't see why we'd want to duplicate that and archive things in one more place. > Or: > > b) a private bug database only used by -hackers to track > known outstanding bugs and patches. This, however, I would find very useful - both as a -hacker and as a user. The point is that only confirmed things should be in there, so only confirmed things should be returned on searches and whatevr. (private not as in not visible to the public, but private as in write-controlled) As a user/admin/whatever, just listing all bugs affecting an installation ("8.0 branch after 8.0.4" for example) so I can evaluate if I need to upgrade is a *very good* thing to be able to do. I realise this adds a bit of overhead for the people doing commits, but it should be possible to integrate that to a point where the overhead is minimized. And it would be a big win. As a -hacker, not needing to keep my own "mailbox format" or "textfile format" bugtracker, and being able to easily find something that would list all communications about a certain bug (*with* links to the archives, where the actual information would still be) would definitly be a win. Tom seems to be able to remember everything in his head and whip out the old commit messages in no time, but I certainly can't ;-) > If you want the latter, the approach would be to keep > pgsql-bugs and when a real issue comes up, bounce it to the > bug tracker. Any subsequent email discussion should then get > logged in the bug report. IMHO, that's the best solution. Except the email discussion lives just fine in the archives, and should be linked back into the tracker if possible instead of copied there. There's also the possibility of c) just using a "bugtracker style interface" as a presentation method over whatever we have now. All our mails go into the archives. If we make sure that all mails about a certain bug are flagged with that bug id (easy enough if it's submitted through the bugs form, I'm sure there can be some voodoo done in majordomo to have it send actual posts to the lists through a script that would do a similar thing), then a tool could fairly easy crawl the archives and pick up all emails related to that bug, and present them separatly. Then if we can convince the committers to always include the bug id when a commit is done for a bug, we'd have the commit messages in the tracker as well... You'd still need someone to fill out metadata like "versions affected" if we want that, but the effort on the "main developers" would pretty much just be to remember to keep the bug id around. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org