Re: bugs that have not been replied-to on list

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: bugs that have not been replied-to on list
Date: 2010-04-19 15:11:47
Message-ID: 14373.1271689907@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> On Sun, Apr 18, 2010 at 9:03 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> What is frustrating about the current process is that ~5% of the bugs don't
>> get a response. How are we going to fix that problem?

> that's a two side problem, while certainly there are valid bug reports
> that fall in the cracks, there are bug reports without a lot of info,
> or with a misguided subject line or that are sent to a wrong list...
> those we will miss no matter what...

I don't think a tracker would actually do much towards that goal.
IME many of the bugs that go unanswered are non-bugs (eg #5316)
or inadequately described (eg #5429), and on any particular day
it may be that nobody feels like expending energy to answer them.
A tracker, at least of the largely-manual kind we've been speculating
about in this thread, would only help for bugs that somebody is willing
to put some effort into.

If the goal is "make sure nothing important slips through the cracks",
a tracker could help. If the goal is "100% response rate to pgsql-bugs
submissions", the only thing that will actually help is a lot more
people willing to do marginally-useful dogwork.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2010-04-19 15:55:41 Re: bugs that have not been replied-to on list
Previous Message Robert Haas 2010-04-19 15:04:00 Re: Re: [BUGS] BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation