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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 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.