Having a popular module sucks

Matts on 2006-09-08T15:24:04

I spent part of the last week fixing bugs in DBD::SQLite and pushing out a new release. I do this out of the goodness of my heart to help people build apps. But having a popular module has its downsides. There are lots of RT bugs to go through. And some of those bugs can be less than helpful.

One such bug was RT bug #20286 which told me that some other CPAN module didn't behave quite right when using DBD::SQLite. That's not much help to me in debugging - I'm not about to download some other huge module off CPAN and figure out all that code and what it does to try and locate my bug.

So I rejected the bug.

The author disagreed with the rejection and re-opened it.

So I rejected it again.

End result: David Muir Sharnoff decides the right thing to do now to get me to fix this "bug" is to give a low rating on cpanratings. What a stupid and lame tactic.

So I'm playing the name and shame game - my equivalent of his lame tactic.


"Was this review helpful to you?" Well, no.

bart on 2006-09-08T16:09:18

The good news is that 0 out of 8 people (no doubt all people that read your post in your journal) found his "review" helpful. I don't know what consequence this may have. Will his vote count less than other people's votes? May it eventually be deleted?

You think that RT was strange...

jk2addict on 2006-09-08T16:16:17

I've seen it happen too...

http://mail-archives.apache.org/mod_mbox/perl-modperl/200512.mbox/%3C4395EF1A.60 10802@chrislaco.com%3E

Well then...

sigzero on 2006-09-08T19:10:06

Can we spam him? >: )

net.kook?

autarch on 2006-09-08T19:53:16

I seem to recall that David Muir Sharnoff is already a reasonably well known net.kook. His Time-modules distro is some sort of weird fork of Graham Barr's TimeDate distro, and I sort of remember that there was some contention about that.

I'd take his silliness with a big grain of salt.

Re:net.kook?

uri on 2006-09-08T20:33:20

and i took over his file::slurp module which had a version number based on the date which is why it is now numbered 9999.12 with the .12 being the real version. also his original list slurp test was broken (which i fixed). finally he bitched at me for 'changing' the behavior of read_file which his original module never specified in the docs, his old code didn't do what he said it did and it had no test for it. my change added flexibity to the api, is documented and tested. and the change was easy to work around for his own user code.

i wouldn't put much weight into his comments.

uri

ticket status

link on 2006-09-08T21:42:15

I would probably have went for stalled instead of rejected but then I can never quite get the hang of bug trackers.

Stalled is indeed probably better

Alias on 2006-09-09T11:04:02

Actually, I think you'd probably be right.

You probably shouldn't reject a bug just because you can't replicate it (where I use "can't" in the sense of "What Matt said").

If you acknowledge that the bug exists, it's simply stalled because you can't do anything to fix it.

oh, this brings back memories...

jhi on 2006-09-10T16:39:13

http://use.perl.org/user/jhi/journal/9711

small example - statements not finalized correctly

link on 2006-09-12T09:06:46

I have added a small example to the rt to illustrate the bug. It looks like disconnecting with statements still in scope causes the disconnect to leak a file handle.