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

From Christopher Browne
Subject Re: Getting a bug tracker for the Postgres project
Date
Msg-id BANLkTinzsFJ=gB73iQ7bGXbPkSzLHEbbDA@mail.gmail.com
Whole thread Raw
In response to Re: Getting a bug tracker for the Postgres project  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Jun 3, 2011 at 8:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Just to throw out a crazy idea, there has been talk of bug ids.  What if
> a thread, made up of multiple message ids, was in fact the bug id, and
> the first message in the thread (ignoring month boundaries) was the
> definitive bug id, but any of the message ids could be used to represent
> the definitive one.
>
> That way, a message id mentioned in a commit message could track back to
> the definitive bug id and therefore be used to close the bug.
>
> If you think of it that way, your email stream is just a stream of
> threads, with a definitive bug id per thread, that is either "not a
> bug", "a bug", " a fix", or "other".
>
> In a way, all you need to do is for someone to add the "thread" to the
> bug system via email, and change its status via email.
>
> Yes, crazy, but that is kind of how I track open items in my mailbox.

That doesn't seem crazy at all...  It seems to parallel the way that
distributed SCMs treat series of versions as the intersections of
related repository versions, each identified by a hash code.

There is one problem I see with the "definitive bug ID," which is that
a thread might wind up discussing *two* problems, and it would be
regrettable to discover that this got forced to be treated as a single
bug.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Getting a bug tracker for the Postgres project
Next
From: Alexander Shulgin
Date:
Subject: Postmaster holding unlinked files for pg_largeobject table