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

Re: Getting a bug tracker for the Postgres project

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kim Bisgaard <kim+pg(at)alleroedderne(dot)adsl(dot)dk>, Greg Stark <gsstark(at)mit(dot)edu>, Joe Abbate <jma(at)freedomcircle(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Getting a bug tracker for the Postgres project
Date: 2011-05-31 09:47:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote:
> I get the feeling we're approaching this backwards. Wouldn't the
> normal way to do it be to define the workflow we *want*, and then
> figure out which bugtracker works for that or requires the least
> changes for that, rather than to try to figure out which bugtracker we
> want and then see how much we have to change our workflow to match?

Maybe you are assuming that there is a single workflow that everyone
wants.  So far we know that most people want to work by email and want
to know that a bug is closed.  Is there more detail than that that we
can extract?

> So in order to start a brand new bikeshed to paint on, have we even
> considered a very trivial workflow like letting the bugtracker
> actually *only* track our existing lists and archives. That would
> mean:
> * Mailing lists are *primary*, and the mailing list archives are
> *primary* (yes, this probably requires a fix to the archives, but that
> really is a different issue)
> * New bugs are added by simply saying "this messageid represents a
> thread that has this bug in it", and all the actual contents are
> pulled from the archives
> * On top of this, the bug just tracks metadata - such as open/closed
> more or less. It does *not* track the actual contents at all.
> * Bugs registered through the bugs form would of course automatically
> add such a messageid into the tracker.

Well, that is not a workflow either, it's approaching the issue by
proposing an implementation.  Nothing says that an existing or new
system doesn't work exactly like that.  I would be concerned about the
search capabilities of such a system, however.

In response to


pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2011-05-31 10:03:06
Subject: Re: Fix for GiST penalty
Previous:From: Nicolas BarbierDate: 2011-05-31 09:32:48
Subject: Re: Cube Index Size

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