Re: BugTracker (Was: Re: 8.2 features status)

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: BugTracker (Was: Re: 8.2 features status)
Дата
Msg-id 20060816170935.GM21363@pervasive.com
обсуждение исходный текст
Ответ на Re: BugTracker (Was: Re: 8.2 features status)  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Wed, Aug 16, 2006 at 09:14:47AM -0400, Andrew Dunstan wrote:
> What we are talking about here is bug triage. Weeding out misreports, 
> duplicates etc. is a prime part of this function. It is essential to the 
> health of any functioning bug tracking system. All it takes is 
> resources. Is it worth it? Yes, IMNSHO, but it's a judgement call.
> 
> One sensible way to do this would be to have a group of suitably 
> qualified volunteers who could perform this function on a roster basis, 
> for, say, a week or a two at a time. That way we could the load off key 
> personnel like Tom (I am in favor of anything which would reduce the 
> demands we place on Tom ;-) )

Actually, I'd bet we don't need to put such a formal system in place. I
suspect that we'll have users actually looking at the incomming bugs and
commenting if they're not valid. As we notice folks who are doing a good
job of that, we can give them the privleges to mark bugs as invalid.

In the meantime, I'd be glad to help out with 'weeding' incomming bug
reports. Depending on the bug tracking system, you can even just let
people do this ad-hoc... bugzilla (for example) has an unconfirmed
status for new bugs; it would just take people looking at all
unconfirmed bugs and marking them appropriately.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


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

Предыдущее
От: Volkan YAZICI
Дата:
Сообщение: Re: libpq Describe Extension [WAS: Bytea and perl]
Следующее
От: Andrew Dunstan
Дата:
Сообщение: timing psql internal commands