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
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 |