Skip site navigation (1) Skip section navigation (2)

Re: Getting a bug tracker for the Postgres project

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Christopher Browne <cbbrowne(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Mailing Lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting a bug tracker for the Postgres project
Date: 2011-05-31 01:52:38
Message-ID: BANLkTik3pRFtGnfzCceOMOJy+uozAnJN7g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, May 30, 2011 at 8:16 PM, Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
> On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)net> wrote:
>> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:
>> > I've summarizes the main points made in the recent discussion and did
>> > some minor additional research on the lists suggested by Peter and
>> > Chris Browne.  Anyone interested in the tracker, please visit
>> > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> > feedback/input.
>>
>> Based on that, and past discussions, and things we've tried in the past,
>> and gut feeling, and so on, it looks like Request Tracker would appear
>> to be the next best thing to consider trying out.  What do people think
>> about that?
>
> My suspicion is that RT may be rather a lot heavier weight in terms of how
> it would have to affect process than people would be happy with.
>
> What has been pretty clearly expressed is that various of the developers
> prefer for the mailing lists and archives thereof to be the primary data
> source and the "venue" for bug discussions.
>
> RT, and Bugzilla, and pretty well the bulk of the issue trackers out there
> are designed to themselves be the "venue" for discussions, and that's not
> consistent with the preference for email discussions.
>
> There are Debian packages for RT 3.8, and I imagine it may be worth tossing
> an instance, but I'd definitely commend trying to minimize the amount of
> deployment effort done, as I think there's a fair chance that a number of
> devs (I'll pick on Greg Stark :-)) are liable to rebel against it.  It'd be
> interesting to see the reactions to the interaction between RT, -hackers,
> and -bugs for a bug or three...
>
> I'd be more optimistic that debbugs, or an adaption thereof, might more
> nearly fit into the workflow.

Yeah, that's my feeling, as well.  I have used RT and I found that the
web interface was both difficult to use and unwieldly for tickets
containing large numbers of messages.  Maybe those those things have
been improved, but frankly if RT or Bugzilla is the best we can come
up with then I'd rather not have a bug tracker at all.  See also:
Linus's opinion on CVS.

I don't personally care if I need to go to a web interface to mark
bugs closed.  Being able to do it via email is possibly useful, but I
don't really care about it personally.  Sounds like we should have it
for the benefit of those who do, but it's not my priority.  What I do
care about is that the tracker doesn't get in the way of *discussion*
of bugs.  IOW, if people just reply-to-all on bug reports as they do
now, and either include some special tag in the subject line or copy
some special address on the CC list, it should all get sucked into the
appropriate bug report.  The number of people reading and replying to
emails on pgsql-bugs is already insufficient, perhaps because of the
(incorrect) perception that Tom does or will fix everything and no one
else needs to care.  So anything that makes it harder for people to
follow along and participate is a non-starter IMV.

Based on the discussion thus far, it sounds like debbugs might be
reasonably close to what we need.

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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-05-31 02:00:43
Subject: Re: switch UNLOGGED to LOGGED
Previous:From: Christopher BrowneDate: 2011-05-31 00:16:56
Subject: Re: Getting a bug tracker for the Postgres project

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group