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

On Thu, Apr 8, 2010 at 5:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> It would certainly be nice if we could just have all bugs reported
> here and sort it out ourselves, but in practice that doesn't seem to
> work. =A0When installer or pgadmin bugs are reported here, they
> typically don't get a response. =A0Eventually I often try to write back
> myself, but if it pertains to something other than core PostgreSQL
> there's little that I can do beyond suggesting that they might want to
> try another forum, so that's what I do. =A0If that's not helpful, I
> could just ignore them altogether, but that doesn't seem better.
>
> Or to put it another way, if someone had written back any time in the
> 13 days between when this email was posted and today and said "thanks
> for the report - will look into it", I wouldn't have replied.

Here are some other bugs that have not been replied to.  A couple of
these are installer bugs, but most of them are just plain old
PostgreSQL bugs.  I've been meaning to try to follow up on some of
these but just haven't had the time.

BUG #5287: ispell dict erroneously returns lexeme on all prefix+suffix
cross products
BUG #5300: Bug on Mac OS X 10.6 and Postgres 8.4
BUG #5316: not handled error in inherit queries
BUG #5335: GUC value lost on exception
BUG #4785: Installation fails
BUG #5337: PostgreSQL install fails with 1603 error
BUG #4806: Bug with GiST index and empty integer array?
BUG #4769: xmlconcat produces invalid xml values -> data corruption
BUG #5379: Adding hunspell-ko dictionary for full-text search doesn't work
BUG #5405: Consol and utf8

...Robert

On Thu, Apr 8, 2010 at 10:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> BUG #5287: ispell dict erroneously returns lexeme on all prefix+suffix
> cross products
> BUG #5300: Bug on Mac OS X 10.6 and Postgres 8.4
> BUG #5316: not handled error in inherit queries
> BUG #5335: GUC value lost on exception
> BUG #4785: Installation fails

I responded to that one:
http://archives.postgresql.org/pgsql-bugs/2009-05/msg00002.php

> BUG #5337: PostgreSQL install fails with 1603 error

That's a PG 8.2/MSI issue, which is why none of the EDB guys
responded. My own excuse is that I'm not the only guy that worked on
the MSI installer, and I simply don't have time to respond to every
problem reported.

> BUG #4806: Bug with GiST index and empty integer array?
> BUG #4769: xmlconcat produces invalid xml values -> data corruption
> BUG #5379: Adding hunspell-ko dictionary for full-text search doesn't work
> BUG #5405: Consol and utf8

This basically indicates that we need an issue tracker. There, look -
now see what you made me do :-(


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Fri, Apr 9, 2010 at 4:43 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Apr 8, 2010 at 10:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> BUG #5287: ispell dict erroneously returns lexeme on all prefix+suffix
>> cross products
>> BUG #5300: Bug on Mac OS X 10.6 and Postgres 8.4
>> BUG #5316: not handled error in inherit queries
>> BUG #5335: GUC value lost on exception
>> BUG #4785: Installation fails
>
> I responded to that one:
> http://archives.postgresql.org/pgsql-bugs/2009-05/msg00002.php

!!!!!  I never got that email message.  Something is wrong with this
mailing list.  In the case of the email that started this discussion,
you never saw the original email message, and in this case, I never
saw your reply.  That's bad.

>> BUG #5337: PostgreSQL install fails with 1603 error
>
> That's a PG 8.2/MSI issue, which is why none of the EDB guys
> responded. My own excuse is that I'm not the only guy that worked on
> the MSI installer, and I simply don't have time to respond to every
> problem reported.
>
>> BUG #4806: Bug with GiST index and empty integer array?
>> BUG #4769: xmlconcat produces invalid xml values -> data corruption
>> BUG #5379: Adding hunspell-ko dictionary for full-text search doesn't work
>> BUG #5405: Consol and utf8
>
> This basically indicates that we need an issue tracker. There, look -
> now see what you made me do :-(

You know, I never really thought we did before, but I had the same
thought last night.  One of the problems with "don't worry about what
product it is, just post here" is that it only works if people from
all of those products regularly monitor this list, which in turn
requires them to skip over the issues with all the other products that
they don't know or care about.  An actual bug-tracking system would
let us classify bugs by product, which would in theory help with this
problem.   Even consider ecpg.  It's part of core PostgreSQL, so
undeniably on topic for this list, but it's asking a lot for Michael
Meskes to read everything that goes by on this list just to catch the
2 or 3 ecpg problems that get reported each year.

Of course, if the people working on those projects don't monitor the
bug-tracking system, then we'll have the same problem with
non-response that we do today - maybe worse, since at least now we can
refer people who don't get an answer to another forum. Another problem
is that any solution we picked would have to be acceptable to the
people who do actively monitor this list.  It would be bad if changing
to a different system resulted in bugs getting less attention.  But
practically speaking, I'd guess there's less than 20 people who
respond to most of the traffic on -bugs, so if we find a solution that
those people like, we'd be better off.

We'd also have fewer problems with things slipping through the cracks.
 Things might still get ignored, but at least the system would be
keeping track of that instead of Bruce and I.  Momjzilla/Haaszilla has
a catchy ring to it but it's not a very efficient way to run a
project.

...Robert

On Apr 9, 2010, at 5:08 AM, Robert Haas wrote:

> Something is wrong with this
> mailing list.=20=20

In the week and a half that I've been subscribed to this mailing list, ther=
e have been several times that I received a reply to a message without rece=
iving the original message. In most cases, I received the original message =
a few minutes to a few hours later. I haven't watched other people's issues=
 closely enough to tell if I'm missing any messages completely. But I can s=
ee why people need to use such long Cc: lists on their posts.

Andy Balholm <andy@balholm.com> wrote:
> On Apr 9, 2010, at 5:08 AM, Robert Haas wrote:
>
>> Something is wrong with this mailing list.
>
> In the week and a half that I've been subscribed to this mailing
> list, there have been several times that I received a reply to a
> message without receiving the original message. In most cases, I
> received the original message a few minutes to a few hours later.

I've seen that sometimes, too.  It's usually preceded by an eerie
"calm" without many (or any) messages.  I don't know whether the
bottleneck is on our end (the emails go through many anti-spam
filters before they reach me, and I know they sometimes fall
behind).

The other issue which has caused me to see replies to messages I
missed is that some of the posters here are going through SMTP
servers on networks segments which have been blacklisted as sources
of spam.  Since I have things configured to not send me duplicates
when the post is to me and a list (or to multiple lists), if a
blacklisted user copies me directly I don't get anything. When I
identify such a user I let them know and get them whitelisted on my
end, but that's hit or miss.

-Kevin

Andy Balholm wrote:
> On Apr 9, 2010, at 5:08 AM, Robert Haas wrote:
>
>> Something is wrong with this
>> mailing list.
>
> In the week and a half that I've been subscribed to this mailing
> list, there have been several times that I received a reply to a
> message without receiving the original message.

I thought that was just my mail server's greylisting messing things up
... but I just realized I turned greylisting off months ago as it'd
become ineffective.

So I'm also getting weirdly-ordered messages. Not just from -bugs,
either ; sometimes I get messages from -general in rather wacky orders,
with replies before originals etc.

--
Craig Ringer

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.

--
Craig Ringer

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


Stefan

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.

On the down side Bugzilla (the only BTS I've any familiarity with) does
produce quite a lot of administrative noise in its email,

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.


Stefan

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.

...Robert

On sön, 2010-04-18 at 13:12 -0400, Robert Haas wrote:
> 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,

There isn't.  Welcome to the show.

;-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


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

Bugzilla is the worst form of bug tracking out there, except for
all the others.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201004181546
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkvLYZUACgkQvJuQZxSWSsh/LACfWCELkWETKE5PVOBWcKF/EhKj
ahoAoNzBtdhiFFoRyrLVn7+KLEwMwE7L
=eP30
-----END PGP SIGNATURE-----

On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.com> wr=
ote:
>> That all sounds pretty reasonable to me, though I would favor using
>> something other than Bugzilla for the tracker. =A0I'm not really sure if
>> there's anything that I'd consider truly good out there, but I've
>> always found Bugzilla pretty terrible.
>
> Bugzilla is the worst form of bug tracking out there, except for
> all the others.

One of these days, I am going to write a @$#! bug tracker.

...Robert

On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.com> =
wrote:
>>> That all sounds pretty reasonable to me, though I would favor using
>>> something other than Bugzilla for the tracker. =C2=A0I'm not really sur=
e if
>>> there's anything that I'd consider truly good out there, but I've
>>> always found Bugzilla pretty terrible.
>>
>> Bugzilla is the worst form of bug tracking out there, except for
>> all the others.
>
> One of these days, I am going to write a @$#! bug tracker.
>

after seen the commitfest app, i can swear the bug tracker you write
should be cool

--=20
Atentamente,
Jaime Casanova
Soporte y capacitaci=C3=B3n de PostgreSQL
Asesor=C3=ADa y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova <jcasanov@systemguards.com.ec> writes:
> On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>>> Bugzilla is the worst form of bug tracking out there, except for
>>> all the others.
>>
>> One of these days, I am going to write a @$#! bug tracker.

> after seen the commitfest app, i can swear the bug tracker you write
> should be cool

... actually, what about minimally modifying the commitfest app to turn
it into a bug tracker?

We keep complaining that none of the existing trackers would integrate
well with our workflow.  ISTM what we basically need is something that
would index the pgsql-bugs archives to show what the current open issues
are.  The commitfest app is dang close to that already.

            regards, tom lane

On Sun, Apr 18, 2010 at 23:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jaime Casanova <jcasanov@systemguards.com.ec> writes:
>> On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas <robertmhaas@gmail.com> wro=
te:
>>> On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.com=
> wrote:
>>>> Bugzilla is the worst form of bug tracking out there, except for
>>>> all the others.
>>>
>>> One of these days, I am going to write a @$#! bug tracker.
>
>> after seen the commitfest app, i can swear the bug tracker you write
>> should be cool
>
> ... actually, what about minimally modifying the commitfest app to turn
> it into a bug tracker?
>
> We keep complaining that none of the existing trackers would integrate
> well with our workflow. =A0ISTM what we basically need is something that
> would index the pgsql-bugs archives to show what the current open issues
> are. =A0The commitfest app is dang close to that already.

Let's not do that without thinking really careful about  it. The
commitfest app is good at what it does precisely because it's designed
to do just that, and nothing more (or less). Twisting it into doing
other things may make things worse rather than better.

That said, basing something off the same ideas can certainly work.

--=20
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Greg Sabino Mullane wrote:
> Bugzilla is the worst form of bug tracking out there, except for
> all the others.
>

flyspray isn't half bad, especially because its really simple and fairly
clean.
supports pgsql too.

On Sun, Apr 18, 2010 at 5:29 PM, Magnus Hagander <magnus@hagander.net> wrot=
e:
> On Sun, Apr 18, 2010 at 23:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Jaime Casanova <jcasanov@systemguards.com.ec> writes:
>>> On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas <robertmhaas@gmail.com> wr=
ote:
>>>> On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.co=
m> wrote:
>>>>> Bugzilla is the worst form of bug tracking out there, except for
>>>>> all the others.
>>>>
>>>> One of these days, I am going to write a @$#! bug tracker.
>>
>>> after seen the commitfest app, i can swear the bug tracker you write
>>> should be cool
>>
>> ... actually, what about minimally modifying the commitfest app to turn
>> it into a bug tracker?
>>
>> We keep complaining that none of the existing trackers would integrate
>> well with our workflow. =A0ISTM what we basically need is something that
>> would index the pgsql-bugs archives to show what the current open issues
>> are. =A0The commitfest app is dang close to that already.
>
> Let's not do that without thinking really careful about =A0it. The
> commitfest app is good at what it does precisely because it's designed
> to do just that, and nothing more (or less). Twisting it into doing
> other things may make things worse rather than better.
>
> That said, basing something off the same ideas can certainly work.

I don't think the code is terribly hard to write no matter how we do
it, and if that means I have to write it, oh well.  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?

...Robert

On Sun, Apr 18, 2010 at 9:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
[...]
> What is frustrating about the current process is that ~5% of the bugs don=
't
> get a response. =C2=A0How 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...

for those that are valid bug reports we would need a team of people
that categorize and/or respond the bugs as soon as they come... like
patch reviewers but they just respond the easy ones, and let difficult
ones for more experienced people, and maybe something like "fix bug
fest" maybe at the end of commit fests?

of course most of this is just a dream, or not?

--=20
Atentamente,
Jaime Casanova
Soporte y capacitaci=C3=B3n de PostgreSQL
Asesor=C3=ADa y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

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

Tom Lane wrote:
> Jaime Casanova <jcasanov@systemguards.com.ec> writes:
>> On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>>>> Bugzilla is the worst form of bug tracking out there, except for
>>>> all the others.
>>> One of these days, I am going to write a @$#! bug tracker.
>
>> after seen the commitfest app, i can swear the bug tracker you write
>> should be cool
>
> ... actually, what about minimally modifying the commitfest app to turn
> it into a bug tracker?
>
> We keep complaining that none of the existing trackers would integrate
> well with our workflow.  ISTM what we basically need is something that
> would index the pgsql-bugs archives to show what the current open issues
> are.  The commitfest app is dang close to that already.

hmm - isn't that basically the implementation I proposed upthread?

As in have a (hyptothetical) tracker being subscribed to -bugs (and
maybe the other lists in the future as well) so the workflow would look
like this:

1a. if somebody submits a request through the webform the tracker
assigns an id and can automatically track all responses on the list
1b. if somebody submits directly to -bugs we could either have the
tracker automatically create an id and track it or we could have a
trivial interface to take a message-id and import on demand

2a. we can simply have the tracker export a dashboard status of:

*) stuff that had no reply too (which is one of the open questions)
*) if a commit has the bug id we could have it autoclose/autotrack that
as well

2b. for the case of "not a bug"/"added to TODO"/"works as
intended"/"pgadmin"/"JDBC" - we would either have to do a trival web
interface to claim so or people could send status updates inline in the
mail(at least the BZ emailinterface can take commands like "@close
NOTABUG" or whatever)

2c. if a bug gets a reply but will never result in a solution per 2a or
2b we could add other dashboard as in "bug replied but no conclusion yet"

Implementing this on our own (if that is about the workflow we want) is
probably not even a lot of work, but we could also use an existing
solution just as the backend engine and do the frontends ourselfs.


Stefan

Robert Haas wrote:
> On Sun, Apr 18, 2010 at 5:29 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Sun, Apr 18, 2010 at 23:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Jaime Casanova <jcasanov@systemguards.com.ec> writes:
>>>> On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>>> On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>>>>>> Bugzilla is the worst form of bug tracking out there, except for
>>>>>> all the others.
>>>>> One of these days, I am going to write a @$#! bug tracker.
>>>> after seen the commitfest app, i can swear the bug tracker you write
>>>> should be cool
>>> ... actually, what about minimally modifying the commitfest app to turn
>>> it into a bug tracker?
>>>
>>> We keep complaining that none of the existing trackers would integrate
>>> well with our workflow.  ISTM what we basically need is something that
>>> would index the pgsql-bugs archives to show what the current open issues
>>> are.  The commitfest app is dang close to that already.
>> Let's not do that without thinking really careful about  it. The
>> commitfest app is good at what it does precisely because it's designed
>> to do just that, and nothing more (or less). Twisting it into doing
>> other things may make things worse rather than better.
>>
>> That said, basing something off the same ideas can certainly work.
>
> I don't think the code is terribly hard to write no matter how we do
> it, and if that means I have to write it, oh well.  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?

by nagging people - if we simply had a dashboard or an email interface
(think of the buildfarm dashboard and the status email reports it
provides to both developers and animalowners) to make the issue more
visible I think most of the problem of "no reply at all" would (mostly)
"solve" itself.


Stefan

Stefan Kaltenbrunner wrote:

> by nagging people - if we simply had a dashboard or an email interface
> (think of the buildfarm dashboard and the status email reports it
> provides to both developers and animalowners) to make the issue more
> visible I think most of the problem of "no reply at all" would (mostly)
> "solve" itself.

As it is, some people on -bugs (myself included despite my lack of much
knowledge of Pg's code base) try to keep track of lost/abandoned reports
and follow them up or poke people who might be able to track down an
issue. Having a tracker would make this considerably easier.

As it is, I think people on -bugs do a pretty decent job of first
contact response (prompt for more details, explain when it's not a bug,
point them at a suitable place to ask some random question, etc) and of
helping people with simpler issues. It's really just that a mail
interface doesn't lend its self well to tracking the status of many
ongoing investigations with long lags, so after that first contact some
of them *do* get lost if there's no follow-up from the poster.

Because of the non-response rate to follow-up requests, IMO any tracker
would *have* to allow triage folks to place bugs in a NEEDINFO / INVALID
/ NOTABUG state, and to report on bugs with no activity in >n days/weeks
so this can be done quickly and easily for non-responsive reporters.

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

Stefan Kaltenbrunner wrote:

> 2a. we can simply have the tracker export a dashboard status of:
>
> *) stuff that had no reply too (which is one of the open questions)
> *) if a commit has the bug id we could have it autoclose/autotrack that
> as well
>
> 2b. for the case of "not a bug"/"added to TODO"/"works as
> intended"/"pgadmin"/"JDBC" - we would either have to do a trival web
> interface to claim so or people could send status updates inline in the
> mail(at least the BZ emailinterface can take commands like "@close
> NOTABUG" or whatever)

That'd be really nice for triage and weeding. Reporting of bugs inactive
for longer than x days/weeks would be really helpful, too, as would
batch actions on them - "post follow-up reminder", "put in INVALID state
due to reporter non-responsiveness", etc.

> 2c. if a bug gets a reply but will never result in a solution per 2a or
> 2b we could add other dashboard as in "bug replied but no conclusion yet"

There are truly a few distinct states:

- New
- Responded, but reponder (who's probably doing triage and not a
  core dev) has no immediate answer. Needs attention from
  more skilled or specialized Pg folks.
- Incomplete report or needs more tracing/debugging/tests run,
  waiting for information from reporter
- Abandoned by non-responsive reporter
- Resolved/closed

with close reasons like:

- Duplicate of #bugid
- This is a help question not a bug report
- This is a feature request not a bug, it should be on the TODO
  (or not, if it's not accepted)
- Working exactly as intended, even if you don't like it or it's
  ugly that it works that way
- Fixed by commit
- Confirmed bug in 3rd party software, forwarded


Pretty much any existing tracker can do this, but especially if you want
a little bit of reporting ... is it really worth building a whole new
one for the job?

IMO all the above would be pretty handy, particularly when people are
looking for things later to reduce duplicate reports, get an idea of
what things confuse people most, etc.

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

On sön, 2010-04-18 at 19:47 +0000, Greg Sabino Mullane wrote:
> > 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.
>
> Bugzilla is the worst form of bug tracking out there, except for
> all the others.

It's funny, but it's true.  After all, a bug tracker is really kind of a
mail reader.

On mån, 2010-04-19 at 09:59 +0200, Stefan Kaltenbrunner wrote:
> 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.

As long as we're approaching this from the point of view that the
current workflow must be kept, we're not going to go anywhere.  Because
the current workflow is 1) Tom fixes all the bugs, and 2) Once in a
while a brave soul is trying to improve things by starting a discussion
such as this.  Which is supported just fine with the current tools.

Despite all the problems with PostgreSQL's bug-tracking system or non-syste=
m, I've found it much nicer to deal with than OpenOffice's.

I really like the fact that it's e-mail based rather than web based. Part o=
f the reason for that is that I have e-mail but not web access, so I can de=
al with it myself instead of trying to get my brother to file bugs for me. =
It's the only bug-discussion list I've seen that you can subscribe to by e-=
mail, and I think that's a great idea.

But that's not the only advantage of having it e-mail based. I think a pers=
onal e-mail response is much more pleasant than a form letter someone gener=
ated by clicking on a web form.=20

By the way, the issue I submitted was more of a feature request than a bug.=
 I sent it to -bugs because I couldn't find a mailing list for discussion o=
f possible new features. If you had (and documented) a list for new feature=
s, it might reduce some of the triage needed on -bugs.

Andy Balholm
(509) 276-2065
andy@balholm.com

Jaime Casanova <jcasanov@systemguards.com.ec> writes:
> On Sun, Apr 18, 2010 at 9:03 PM, Robert Haas <robertmhaas@gmail.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

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> IME many of the bugs that go unanswered are non-bugs (eg #5316)
> or inadequately described (eg #5429)

Agreed.

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

Actually, if we had has something I could review to easily spot them
as unanswered, I probably would have responded to #5316 long ago.
(I'm not sure whether it makes sense to respond after two and a half
months.)  I don't know whether the message fell victim to our
(rather aggressive) spam filters or I initially blew past it for
some reason, but had I been able to review a list of pending issues,
I'm sure I'd have picked it up.

I intentionally skipped #5429 because I thought the description in
the post might mean something to someone familiar with ODBC access
to PostgreSQL.  If we had a tracking system, I'd have probably
responded if nobody else did after two or three days, to suggest
another list or request more detail.

I will often hang on to emails to which I don't initially reply, to
remind me to follow up, but I find that clumsy and error-prone, and
I have the disheartening feeling that there are other people doing
exactly the same thing, leading to duplicated (wasted) effort.

I don't think it has to be fancy, but setting up something to track
open issues (linking to the related list archive pages) seems like
a good idea to me.

-Kevin

On Mon, Apr 19, 2010 at 11:55 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> IME many of the bugs that go unanswered are non-bugs (eg #5316)
>> or inadequately described (eg #5429)
>
> Agreed.
>
>> If the goal is "make sure nothing important slips through the
>> cracks", a tracker could help. =A0If 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.
>
> Actually, if we had has something I could review to easily spot them
> as unanswered, I probably would have responded to #5316 long ago.
> (I'm not sure whether it makes sense to respond after two and a half
> months.) =A0I don't know whether the message fell victim to our
> (rather aggressive) spam filters or I initially blew past it for
> some reason, but had I been able to review a list of pending issues,
> I'm sure I'd have picked it up.
>
> I intentionally skipped #5429 because I thought the description in
> the post might mean something to someone familiar with ODBC access
> to PostgreSQL. =A0If we had a tracking system, I'd have probably
> responded if nobody else did after two or three days, to suggest
> another list or request more detail.
>
> I will often hang on to emails to which I don't initially reply, to
> remind me to follow up, but I find that clumsy and error-prone, and
> I have the disheartening feeling that there are other people doing
> exactly the same thing, leading to duplicated (wasted) effort.
>
> I don't think it has to be fancy, but setting up something to track
> open issues (linking to the related list archive pages) seems like
> a good idea to me.

+1.  There seem to be several people, including Kevin, Craig Ringer,
and myself, who are trying to make sure that everyone gets some kind
of a response, but it's hard to organize it when we're all relying on
our own email boxes (and let's not forget the fun and excitement of
the mailing list failing to deliver an occasional message to one or
more of us).

...Robert

On Mon, Apr 19, 2010 at 5:02 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On m=E5n, 2010-04-19 at 09:59 +0200, Stefan Kaltenbrunner wrote:
>> 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.
>
> As long as we're approaching this from the point of view that the
> current workflow must be kept, we're not going to go anywhere. =A0Because
> the current workflow is 1) Tom fixes all the bugs, and 2) Once in a
> while a brave soul is trying to improve things by starting a discussion
> such as this. =A0Which is supported just fine with the current tools.

As far as I am concerned, this is just bellyaching.  I'm glad Tom
fixes most of the bugs because otherwise we would have a lot more
unfixed bugs.  But he's not from the only one who responds to bug
reports, and we seem to have a pretty good consensus on what a better
system for the other people involved in the process would look like.
Please don't get in the way of efforts to try to put such a thing in
place.

...Robert

On mån, 2010-04-19 at 15:37 -0400, Robert Haas wrote:
> As far as I am concerned, this is just bellyaching.  I'm glad Tom
> fixes most of the bugs because otherwise we would have a lot more
> unfixed bugs.  But he's not from the only one who responds to bug
> reports, and we seem to have a pretty good consensus on what a better
> system for the other people involved in the process would look like.
> Please don't get in the way of efforts to try to put such a thing in
> place.

Oh I'm not getting in your way.  I'm just not very optimistic that a
thin layer over a mailing list is going to help much.

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> As in have a (hyptothetical) tracker being subscribed to -bugs (and maybe
> the other lists in the future as well) so the workflow would look like
> this:

Well there is a WIP to use an ArchiveOpteryX based solution to replace
the archives and get rid of the artificial breaking of pages. My guess
is that adding a status table linking to emails and that a set of
volunteers (they gave their names!) maintain would make our day.

> 1a. if somebody submits a request through the webform the tracker assigns an
> id and can automatically track all responses on the list

The AOX archive based system has a nice thread view based on some CTE
queries. Assigning an ID to emails that are not a response shouldn't be
hard to do in a trigger if necessary, and parsing the email subject line
for cases when the ID exists looks feasible too.

> 1b. if somebody submits directly to -bugs we could either have the tracker
> automatically create an id and track it or we could have a trivial interface
> to take a message-id and import on demand

AOX will just archive the mail in its PostgreSQL database upon
receiving, it's just another subscriber to the list.

> 2a. we can simply have the tracker export a dashboard status of:
>
> *) stuff that had no reply too (which is one of the open questions)
> *) if a commit has the bug id we could have it autoclose/autotrack that as
> well

That would be a set of queries with some dynamic web scripting
around. Plus the all the work to get to a usable WebUI of course.

> 2b. for the case of "not a bug"/"added to TODO"/"works as
> intended"/"pgadmin"/"JDBC" - we would either have to do a trival web
> interface to claim so or people could send status updates inline in the
> mail(at least the BZ emailinterface can take commands like "@close NOTABUG"
> or whatever)
>
> 2c. if a bug gets a reply but will never result in a solution per 2a or 2b
> we could add other dashboard as in "bug replied but no conclusion yet"

The triage would have to be manual. Or we could have some nice Tsearch
based queries to parse the mail content and offer an AI based dashboard
of waiting bugs. Sounds fun, he?

> Implementing this on our own (if that is about the workflow we want) is
> probably not even a lot of work, but we could also use an existing solution
> just as the backend engine and do the frontends ourselfs.

Did I mention AOX and the work in progress for the archives? :)
--
dim

On Wed, Apr 28, 2010 at 4:09 PM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> As in have a (hyptothetical) tracker being subscribed to -bugs (and maybe
>> the other lists in the future as well) so the workflow would look like
>> this:
>
> Well there is a WIP to use an ArchiveOpteryX based solution to replace
> the archives and get rid of the artificial breaking of pages. My guess
> is that adding a status table linking to emails and that a set of
> volunteers (they gave their names!) maintain would make our day.

It would be great to leverage that.  Is there any chance of that
getting finalized and deployed to production some time in the
forseeable future?

...Robert