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

Robert Haas wrote:
> On Sun, Apr 11, 2010 at 7:14 AM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>> Jasen Betts wrote:
>>> On 2010-04-10, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote:
>>>> Craig Ringer wrote:
>>>>> Dave Page wrote:
>>>>>
>>>>>> This basically indicates that we need an issue tracker. There, look -
>>>>>> now see what you made me do :-(
>>>>> Please?!?
>>>>>
>>>>> I wonder, if EDB just went ahead and set one up, would people start
>>>>> using it? I've been tempted to do it myself, but I'm not confident I can
>>>>> handle the bandwidth/hosting for a decent tracker with upload capability
>>>>> etc.
>>>>>
>>>>> Or just use Launchpad. It's actually pretty good, and very accessible,
>>>>> plus many people already have logins.
>>>>>
>>>>> I know people are worried it'll just become full of many ignored,
>>>>> dupliate or useless reports, but that's what -bugs is anyway; it's just
>>>>> less visibly so. Dups and non-bugs are easily closed by the same folks
>>>>> who're active on -bugs triaging here.
>>>> the problem is not setting one up (in fact we had multiple serious
>>>> attempts at that) but more of how it should interact with the lists, what
>>>> tool we should use and "do we even want one". There are tons of discussions
>>>> on that very topic in the archives (and also in the wiki).
>>> you could set the Bug tracking system to CC every report to the list and
>>> possibly have the list refuse posts that are replies to these
>>> autoposts so that responses must go through the BTS. alternately you
>>> could possibly set something up so that responses also go into bug
>>> report on the BTS.
>> the original plan was to keep the bug report form as it is and just call out
>> to the BTS to get a bug id. The form would then just sent the report like it
>> does now. The difference would have been that the tracker is subscribed to
>> the list and because it "knows" about the bug-id in question it could
>> actually track all the responses as if they were created through the BTS.
>> That way the only thing left to do in the BTS would have been actually
>> marking a bug as closed/todo/whatever - it would be trivial however to
>> generate the kind of stuff robert generated manually like "bugs nobody
>> replied to yet" or "bug not replied to within X days".
>> The prototype we had used bugzilla's xml-rpc interface and the
>> email-interface for this but i guess you can do similiar things with other
>> trackers.
>
> That all sounds pretty reasonable to me, though I would favor using
> something other than Bugzilla for the tracker.  I'm not really sure if
> there's anything that I'd consider truly good out there, but I've
> always found Bugzilla pretty terrible.  Then again, a bird in the hand
> might be worth two in the bush.

well BZ is terrible (but so are all the other trackers) - but for the
usecase I envisioned I would actually just use it as the backend engine
and have a few selected views "not replied yet", "not closed" etc juste
exported on a dashboard (or as an RSS feed).
I think we would not even need to expose the webinterface to the wider
community, what we probably want is something that let's us keep the
current workflow but provides a minimalistic status/statistics/dashboard
feature on top.


Stefan