Message-ID: <4F8EF527.1020603@agliodbs.com>
Date: Wed, 18 Apr 2012 10:08:55 -0700
From: Josh Berkus <josh@agliodbs.com>
Organization: PostgreSQL Experts Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: Bug tracker tool we need
References: 
 <CA+Tgmoa75QujxzCZC+dj=0+JayGPhJD2kQMDBmbGmmq_HPgHxw@mail.gmail.com>
	<1334165303.25392.9.camel@vanquo.pezone.net>
	<28338.1334168965@sss.pgh.pa.us>
	<1334180206.25392.39.camel@vanquo.pezone.net>
	<CA+TgmoariJzLZ-9CfhF-Xwezk=UbmG_WUk5KydPYb8qFJzgkXw@mail.gmail.com>
	<1334350086.9019.16.camel@vanquo.pezone.net>
	<878vhyeqyq.fsf@commandprompt.com> <4F89ED6C.4030609@gmail.com>
	<87d379mwan.fsf@commandprompt.com>
	<1334540156-sup-2520@alvh.no-ip.org>
	<878vhwnjhv.fsf@hi-media-techno.com>
	<877gxf7ihf.fsf_-_@commandprompt.com> <4F8C93B2.1000503@gmail.com>
	<CA+TgmobGU2LfCdrmXG0DW9HbN5qXAx2Uvh2swrWs38b-qJR-CA@mail.gmail.com>
	<14172.1334716224@sss.pgh.pa.us> <4F8E3394.5040801@2ndQuadrant.com>
	<19323.1334720651@sss.pgh.pa.us>
	<CABUevEzNikdGj0CF--Km0F6-hzcCpGVB9NQ0JJV5BXoAaDRsCA@mail.gmail.com>
	<CA+TgmoaogveGkqJLmHNTKgLB9hDG+NcCX9gT_4x2yTHhERBc3A@mail.gmail.com>
	<1334758503.29544.14.camel@vanquo.pezone.net>
	<CA+TgmoZdt5pwgFUf6RHTTG_KhtLdR=XSEvRHQgGVh1fWUv7k6g@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoZdt5pwgFUf6RHTTG_KhtLdR=XSEvRHQgGVh1fWUv7k6g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Robert, Peter, all:

>>> 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.

... most of them, actually.

>> 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:

I think assuming we can use the *same* tool for the CommitFests as for
tracking bug reports would be a mistake.  The workflow for both things
is very different.

> 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.

Well, that *is* a workflow, even if it's a very simple one.  And it
could (should) be handled by a very simple bug tracker with a very
simple workflow; as much as it irritates me otherwise, Bugzilla does
this with its 4-5 bug "statuses", although the whole "assignment"
approach wouldn't really work for us.  Frankly, the concept of
"assignment" doesn't work very well for OSS projects, period, in my
experience.  Often as not, it simply means that one person is ignoring
the bug instead of a whole group of people.

So a simple bug tracker which has four statuses (
"Submitted","Verified","Fixed","Invalid") would describe our entire bug
workflow.  Pretty much every bugtracker available can do this minimal
level of bug tracking.

BTW, given our heavy reliance on email, let me put a word in here for
RT, which is 100% email-driven.  RT has other limitations, but if your
goal is to never log into a web interface, it's hard to beat.

> wontfix.  We don't need a system to help us ignore bug reports; our
> existing process handles that with admirable efficiency.

I think I have this year's pgCon T-Shirt quote. ;-)

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com