Re: Bug tracker tool we need

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, Alex <ash(at)commandprompt(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug tracker tool we need
Date: 2012-04-18 14:29:26
Message-ID: CA+TgmoZdt5pwgFUf6RHTTG_KhtLdR=XSEvRHQgGVh1fWUv7k6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 18, 2012 at 10:15 AM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-04-18 14:47:37 Re: nodes/*funcs.c inconsistencies
Previous Message Andrew Dunstan 2012-04-18 14:27:08 Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen