Re: Bug tracking (was Re: +/- Inf for float8's)

Поиск
Список
Период
Сортировка
От Adam Haberlach
Тема Re: Bug tracking (was Re: +/- Inf for float8's)
Дата
Msg-id 20000821102818.A20354@ricochet.net
обсуждение исходный текст
Ответ на Re: Bug tracking (was Re: +/- Inf for float8's)  (Don Baccus <dhogaza@pacifier.com>)
Ответы Re: Bug tracking (was Re: +/- Inf for float8's)  (Don Baccus <dhogaza@pacifier.com>)
Список pgsql-hackers
On Mon, Aug 21, 2000 at 07:35:10AM -0700, Don Baccus wrote:
> 
> >At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:
> >>If you all don't mind, I think it'd be great to keep this discussion on the
> >>list.  As some of you know, Great Bridge is working on its own project
> >>hosting site (including a PG-backed bug tracking module).  We're not quite
> >>ready to pull back the curtain yet, but are getting close, and will be
> >>actively soliciting input (and hacks) from the community.
> 
> Another implication which missed me first time 'round is that Great Bridge
> might be planning to have its own bug reporting system, separate from 
> that used by the development community at large?
Cool your conspiracy theories.  I'm not yet involved with either side
of this discussion, but before it runs out of control...

> I hope not.  There should be one central place for bug reporting.  If 
> Great Bridge wants to run it, fine, also if Great Bridge wants to be able 
> to incorporate some sort of prioritization system for those with paid
> support (or some other discriminatory system) it is still probably better
> to figure out a way to accomodate it rather than have two separate 
> bug reporting systems.
The fact is that postgres already has a very good system for keeping
track of issues from report to fix to verification.  So far the main defect
is the obvious one of "People don't know the history unless they troll the
message archives or lurk".  Everyone here is leery of "fixing" a working
system.  Especially when it entails modifying the working system to deal
with a new issue database.
Bug Database/Issue Trackers can be done in two ways.

Someone can grab an off-the-shelf system like Bugzilla or this ArsTechnica 
thing and then try to make the project conform to it.  So far, everyone 
I've talked to who has touched Bugzilla has said that it sucks.  I don't 
know anything about this other proposed system but it will probably require
a lot of time to even get people to use it regularly, much less use it well.

The other method is to create the system to match the process in place.
Since the postgres project is already very well organized, I personally would
like to see the custom system, rather then make Bruce throw away his TODO
list and use someone else's idea of an issue tracking system.  It takes a lot
more work--someone has to pay attention to what is going on with the project
and make sure the database stays in sync, but in the long run, it is less
disruptive and smoother to integrate into an already working project like
this one.


-- 
Adam Haberlach             | "A farm tractor is not a motorcycle."
adam@newsnipple.com        |   --California DMV 1999
http://www.newsnipple.com/ |        Motorcycle Driver Handbook


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tiago Antão
Дата:
Сообщение: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan