Re: BugTracker (Was: Re: 8.2 features status) - Mailing list pgsql-hackers

> 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