Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

iburrell (4155)

iburrell
  ianburrellNO@SPAMgmail.com
http://znark.com/
AOL IM: imburrell (Add Buddy, Send Message)
Jabber: ianburrell@gmail.com

Journal of iburrell (4155)

Sunday September 17, 2006
08:27 PM

CPAN Black Hole

[ #31032 ]
I hate CPAN maintainers who don't respond to bugs. I have been putting in bugs for problems I find in various CPAN modules. For some, I have even put in patches which fix the bug. The result has been complete silence.

I don't expect maintainers to drop everything and fix the bug. I would hope that they would at least send an acknowledgement that they have seen the bug and might work on it. A snarky "that is not a bug but a feature", "it has been fixed in the latest release", or "you are an idiot, do this instead" is better than silence.

If you post a module to CPAN, you have an obligation to maintain it. I suspect fixing bugs is more beneficial to the community than writing new, cool stuff. Even if it is really boring. The user has an obligation to report bugs if they encounter them so the maintainer is not in the dark. One big advantage of open source is that the user can provide a fix or at least a test case. The maintainer's responsiblity is to apply the patch if it is suitable. Not let it sit there gathering dust.

The best example is bug 27, a major limitation in URI which is only 5 years old. People have even provided patches.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

CPAN Black Hole 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • There are plenty of modules whos maintainers have fixed the bugs, but not closed the tickets. (FormValidator::Simple).

    Some people have tickets that are old, but the original posters never responded to requests for more information (Net::Blogger).
    • The important thing is that the bugs get fixed. Or at least triaged. If the requestor doesn't respond to the request for info, then it is their problem.

      And the maintainer doesn't have to go through huge amounts of effort to fix huge or poorly specified bugs. But there is a minimum amount of effort.

  • CPAN authors don't have to do anything, and they owe nothing to you. Given the option of nothing on CPAN, and something I can fix myself, I'll take the latter.

    As a module author myself, I try to respond to all problems as quickly as I can. However, it's not part of my job and it's not very high on my life priorities. Although I try to be helpful and timely, I feel absolutely no obligation to respond to bug reports, fix modules, or otherwise do anything that's less important than whatever I decide I would li
    • It was a rant. It was meant to be intemperant. I am professional and polite when reporting bugs. I don't literally hate unresponsive maintainers since that likely includes friends of mine. "Slightly annoyed" doesn't get a response.

      At work, we do patch, subclass, and work around bugs. But nobody else ever sees those fixes. That is why users should have the courtesy to report bugs and ideally fix them. The maintainer should have the courtesy to respond. In the easy case, they check and apply the pa

      • It would be wonderful is all maintainers could respond. I wouldn't think that they read messages from users and think "I'm going to be an asshole today and not respond". Remember that they are people too, have lives, jobs, families, and so on, and simply might not have time to respond. With spam filters, they may have never seen your messag. Withthe volume of mail they get, they might be overwelmed with all sorts of mail. They may not be using their CPAN mail address anymore, for whatever resaon, so your ma
  • Reading your post, I had an "I wonder if..." thought and checked the bug report. Yup. Eleven months agoI found and reported the same bug, noting that bug 27 had the fix, and adding a pointer to the W3C recommendation. Sad that the (one line) fix hasn't been applied, since URI is part of the core distribution.
    • URI is part of the core distribution

      It's not part of the core perl distribution. It may be part of Activestate's distribution, but that's not the same thing.

      • What comes with the ActiveState distribution is "what comes with Perl" for a very large swatch of the user community. But you're right, it isn't core. I stand corrected.
    • I looked at the fix to the URI module, and after about an hour stop working on it. There are several problems with the one-character patch:

      * It only breaks apart URIs, it doesn't put them back together

      * The parser needs to break on either a ; or a &, not both of them at the same time. Although there shouldn't be both, I'm painfully aware that "shouldn't be" means "is".

      * There is no way for the programmer to tell URI which delimiter to use. This is the rather troublesome part because it has implications

      • We had need of scanning URLs, not generating them. So, I'm embarrased to admin, I completely ignored the generation issue when figuring out a one-line patch and generating the bug report. Generating URLs is more complicated, because you'd need a way to specify whether you're going to emit them into HTML or XHTML. And the W3C recommendation isn't crystal clear on what the rules are. Oh yeah, and tests.

        Sigh.

        • Generating URLs is more complicated, because you'd need a way to specify whether you're going to emit them into HTML or XHTML.

          That appears to make no sense whatsoever.

          • More context. If you're generating a URL to go into HTML, you typically use & to separate paramaters. For XHTML, if you're playing by the rules, you have the option of using & or ;

            Surprised me, too, but it's in the W3C recommendation.

            • But that rule applies to any content you put in XHTML or HTML documents. The fact that it’s a URI is a red herring.

              Putting entity escaping into the URI processing code is bad distribution of responsibilities. It is the caller’s job to put the URI through entity escaping when the output necessitates it.

              • HTML doesn't require that the amperand (when used to separate key value pairs) be escaped in hrefs; XHTML does.

                See http://www.w3.org/TR/xhtml1/#C_12 [w3.org]

                • Arg. That was supposed to be a preview, and not a post. I'd intended to add that while ensuring correct escape for XHTML is the programmers responsiblity, adding another layer of escaping into the pipeline after URI, rather than having a flavor of URI that knows how to escape for XHMTL, seems to me as thought it's putting the burden into the wrong place.

                  • That makes the least sense yet. If the program is outputting URIs in HTML, it is outputting HTML, and so it has to deal with properly escaping content in other contexts anyway. What differentiates URIs from other content such that piercing the separation of concerns is sensible in their case?

                • It should be escaped in HTML too. The fact that it mostly works if you don't escape them, is thanks to browsers that try to accept anything people throw at them and make sense of it.

                  But, like someone else said, the HTML escaping has nothing to do with the fact that it's an URL. Any attribute of a HTML tag ought to be escaped. It is an extra layer on top of the content, but it is not part of the content itself. For example, the content of the attribute bar in the tag <foo bar="a&amp;b"> is "a

  • > If you post a module to CPAN, you have an obligation to maintain it.

    We don't make CPAN module authors to sign any contracts. And even if we did, we could not enforce them, nor would we want to.
  • I tend to roll up bug fixes to "when I have time". My life is busy, and I do this stuff for free, and your tone is a little ungrateful. I don't like it much when people tell me I'm taking too long to fix bugs in free code.
    • While I understand you and brian d foys responses and agree sometimes the nasty tone doesn't help anyone, I understand the posters frustrations as well.

      If it was a matter of an internal application where you can just patch and go, then the issue isn't so bad. However, if the module is a prereq for another module getting pushed to CPAN, maybe even a major release, it's pretty frustrating having to either put a hold on development, wait for a takeover and rerelease, or fork to get the job done.

      I lucked out bi
    • Thanks for fixing bugs (and writing modules in the first place). Fixing bugs is a lot of work and it isn't fun work. Doing them in batches, even yearly, is okay as long as it happens. I am actually not asking that maintainers should drop everything and fix bugs. And they don't have a duty to do the work on their spare time. I am much more interested in getting a response: "Thanks for the patch", "I'll look at it later", or even "That is stupid". And knowing that it will be worked on someday.

      • Yeah, I agree. It’s the impenetrable silence that is a bother. The type of response matters little, as long as there is one.

        Heck, even rejecting the bug saying “I don’t care, get lost” would be acceptable. At least then I know not to care anymore either and can proceed to evaluate my last-resort options (fork, switch modules, etc) with confidence that such was indeed necessary.

      • In the one case you cite, Gisle, the author or the module, did respond initially.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.