Re: Bug tracker tool we need - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Bug tracker tool we need
Date
Msg-id CA+TgmoZdt5pwgFUf6RHTTG_KhtLdR=XSEvRHQgGVh1fWUv7k6g@mail.gmail.com
Whole thread Raw
In response to Re: Bug tracker tool we need  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Bug tracker tool we need
Re: Bug tracker tool we need
List pgsql-hackers
On Wed, Apr 18, 2012 at 10:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote:
>> It's very tempting to assume that the problem we're trying to solve
>> must already have been well-solved by someone else, and therefore we
>> ought to use their thing instead of inventing our own.  But that
>> presumes that our problem is exactly the same as other people's
>> problem, which may not really be true.
>
> It's also very tempting to assume the opposite. ;-)

Fair enough.

>> IME, bug trackers typically work best when used by a tightly
>> integrated team.
>
> Well, very many loosely distributed open-source projects use bug
> trackers quite successfully.
>
>> So I think Greg has exactly the right idea: we shouldn't try to
>> incorporate one of these systems that aims to manage workflow;
>
> Um, isn't half of the commitfest app about workflow?  Patch is waiting
> for review, who is the reviewer, patch is waiting for author, who is the
> author, patch is ready for committer, who is the committer?  And every
> week or so the commitfest manager (if any) produces a report on patch
> progress.  Isn't that exactly what these "workflow management" systems
> provide?

Yeah, but I thought we'd veered off into a digression about tracking
bug reports.  Here's our workflow for bugs:

1. If they seem interesting, Tom fixes them.
2. Or occasionally someone else fixes them.
3. Otherwise, they drift forever in the bleakness of space.

I've been conducting the experiment for a year or two now of leaving
unresolved bug reports unread in my mailbox.  I've got over 100 such
emails now...  and some of them may not really be bugs, but nobody's
put in the work to figure that out.  It would be useful to have a
system that would keep track of which ones those are so people could
look over them and maybe get inspired to go do some bug-fixing, or at
least bug-analysis, but what good is workflow going to do us?  We
could "assign" all those bugs to people who are "supposed" to look at
them, and maybe some of those people would actually do it, but a more
likely outcome is that everybody's list of assigned issues would
slowly converge to infinity, or they'd just start closing them as
wontfix.  We don't need a system to help us ignore bug reports; our
existing process handles that with admirable efficiency.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen
Next
From: Robert Haas
Date:
Subject: Re: nodes/*funcs.c inconsistencies