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

On Wed, Apr 18, 2012 at 10:29:26AM -0400, Robert Haas wrote:
> >> 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

I saved this email from April and have given it some thought.  I decided
to approach it by looking at our current workflow, then deciding what
the problems were, rather than approaching it with "we need a bug
tracker".

I started by drawing a diagram of our current development process:
http://momjian.us/main/writings/pgsql/work_flow.pdf

I did this so I could see the weaknesses.

First, the left and right sides are what our users see, and the middle
is controlled by developers.  

Looking at the chart, the three sections, left, middle, and right, seem
to work fine in isolation.  Our interaction with bug reporters is very
good, our development flow seems fine, and people are certainly happy
with the quality of our releases.  Yes, there are problems, like the
ability of patches to get lost, but in general, things are good.

I think our big gap is in integrating these sections.  There is no easy
way for a bug reporter to find out what happens to his report unless the
patch is applied in the same email thread as the report.  It is hard for
users to see _all_ the changes made in a release because the release
notes are filtered.

Our current system is designed to have very limited friction of action,
and this give us a high-quality user experience and release quality, but
it does have limits in how well we deal with complex cases.

OK, now for the question about a bug tracker.  A bug tracker would
provide a track-able contact for everyone reporting a bug, and allow
them to see exactly what release fixes the bug (in an ideal world).  It
also allows for more detailed reporting of what is each release.  

For me, the big problem with a bug trackers is that it adds so much
friction to the development process, meaning fewer people are involved
and less work gets done.  If you have company-sponsored development, you
can just hire more people to overcome that friction, but for volunteer
development, I am not sure a bug tracker really works well, and given
the chaotic content in almost every bug tracker database, I think that
is true.

So, my question is, what can we do to better integrate these sections? 
Assign a bug number on email that gets stamped on the commit and release
note item?  Add email notification of commits somehow?  Should we
publish the entire git log for each release?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +