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

Re: Getting a bug tracker for the Postgres project

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL Mailing Lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting a bug tracker for the Postgres project
Date: 2011-05-31 13:30:15
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Tue, May 31, 2011 at 15:07, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 05/31/2011 04:01 AM, Peter Eisentraut wrote:
>> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
>>> One of the conclusions the study group came to was that there should
>>> be good integration between the tracker system and the SCM. That was
>>> in the days before distributed SCMs were common, and in a commercial
>>> context, so I'm not sure how well our reasoning would stand up for the
>>> current context, but I see it's been mentioned elsewhere and I think
>>> it's a significant consideration, at least.
>> What kind of functionality would (good) SCM integration provide?
> Well, the most obvious one is that when a commit (or merge or push) is made
>  that fixes a bug, the bug is annotated and its status updated. I know I've
> wasted plenty of time in the past first hunting for bugs and then hunting
> for the fixes, which aren't always clear from the commit messages.

As long as we properly track email, we don't actually need a direct
integration with the SCM for this - since we send the commit message
out to the -committers list anyway, we just need to pick it up there.

> In a more centralized system you can also have fairly tightly integrated
> workflow (e.g. you can have the tracker open a branch when a bug is
> assigned, and you can prevent one being created without an issue being
> assigned) but that doesn't seem like such a good fit for us, nor for anyone
> using a distributed system like git. You could also argue that it's a bad
> thing for commercial organizations, but that's a debate for another place.
> The reason we wanted such a thing is that we were spending significant time
> managing the workflow issues, and doing tidy up.

Yeah, that does sound like a very bad idea *for us*.

 Magnus Hagander

In response to

pgsql-hackers by date

Next:From: ktm@rice.eduDate: 2011-05-31 13:30:21
Subject: Re: Getting a bug tracker for the Postgres project
Previous:From: Simon RiggsDate: 2011-05-31 13:22:52
Subject: Re: Reducing overhead of frequent table locks

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