Re: Commit fest queue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Commit fest queue
Date
Msg-id 874pa8gvrp.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Commit fest queue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Commit fest queue  ("Brendan Jurd" <direvus@gmail.com>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> The bug trackers I've dealt with haven't got much flexibility in this
> respect either --- the sorts of global views you can get are entirely
> determined by the tool. I'm fairly certain that a tracker designed around
> the assumption that different entries are essentially independent isn't
> going to be very helpful.

The bug trackers I've dealt with did have some way to merge bugs, though
obviously nothing as flexible as a wiki page.

Debbugs allows you to merge two bugs in which case the two bug#s are synonyms
for each other. All messages related to either bug appear in one list and
there's only one set of status bits for both bugs.

Bugzilla allows you to mark bugs as duplicates but basically this amounts to
marking one bug as a duplicate and closing it. Both bugs get notes indicating
the other bug# but you have to click on a link to see the info attached to the
closed duplicates.

I've noticed Mozilla creates a lot of "tracking" bugs for classes of problems.
I think this is related to your observation. The tracking bug just lists all
the other related bugs which fall under that topic.

I'm sure trac has a solution for this, I'm curious to hear how it works.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Cached Query Plans (was: global prepared statements)
Next
From: Rick Gigger
Date:
Subject: Re: Commit fest queue