Re: Getting a bug tracker for the Postgres project - Mailing list pgsql-hackers

From Joe Abbate
Subject Re: Getting a bug tracker for the Postgres project
Date
Msg-id 4DE3AF43.2070900@freedomcircle.com
Whole thread Raw
In response to Re: Getting a bug tracker for the Postgres project  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Hi Magnus,

On 05/30/2011 08:45 AM, Magnus Hagander wrote:
> It's fine that a bug tracker *tracks* bugs. It should not control
> them. That's not how this community currently works, and a lot of
> people have said that's how they want it to stay (at least for now).

If I may belabor the point, what do you see as an example of
"controlling" the bugs?  To put some context, there could be at least
three ways a bug could be closed when someone commits a patch that fixes
(or claims to fix) a bug:

a. The committer has to use a web interface to indicate the bug is closed
b. The committer has to send an email to a mail interface
c. The commit message gets routed to a mail interface that, seeing
something like "bug #1234" in the first line, automatically closes the bug

Based on the discussion so far, it's obvious that option b is more
desired than a (where the tracker is, in a sense, controlling *you*),
but is option c --while presumably more desirable since there's one less
thing to do or remember-- an instance of "control", since the tracker
takes an automatic action?  Or do you want the tracker *not* to require
or take any of the actions, i.e., let someone/thing other than the
committer/commit message worry about tracking the bug's status, leaving
it up to volunteers, as Tom said?

Joe


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Nested CASE-WHEN scoping
Next
From: Tom Lane
Date:
Subject: Please test peer (socket ident) auth on *BSD