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.
Re:Even better.
iburrell on 2006-09-18T01:57:51
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.
Re:Take a deep breath
iburrell on 2006-09-18T15:26:52
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 patch. For harder bugs, a response opening the bug is just fine. In fact, the rant was caused by me making sure to get all the bugs encountered entered. Many of them had already been fixed in the later version. Most of the others got fixed or at least looked at. But a few are still sitting untouched after a while.
I also wonder if there are things in the system which can be improved. CPAN has the model of a single person responsible for a module. Only the maintainer can respond to bugs and produce new releases. Would it help having people who can triage bugs? Or people could open up access to version control? We could mark how responsive maintainers are in search.cpan.org. It shows the number of bugs but that doesn't show how long those have been sitting there.
Re:Take a deep breath
brian_d_foy on 2006-09-18T18:40:43
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 mail might be sitting in an account that they never read. There is absolutely no information you can glean from a non-response, so you shouldn't assign any character defects, malicious intent, or anything else to a lack of a response.
CPAN does not have a single maintainer model. Many people can simultaneously work on, maintain and release a module. The module author can add co-maintainers at any time through the "Change Permissions" panel of PAUSE. If the author has disappeared, a PAUSE admin can add you (write to modules@perl.org).
No matter what the CPAN model is, that doesn't imply any structure on what else other people can do, such as triaging bugs, developing full patches with tests, and so on.
CPAN Search already marks the responsiveness of maintainers by showign the release dates of their work. It's an indirect measure, but as good as you will get.
As a user, you should do a bit of homework before you start complaining. Ask questions first and rant later. Going off without knowing the situation, and making up conspiracies where there is no information does not win you friends. Again, as I saqid previously, part of your problem is you.
Re:This one is sad
nicholas on 2006-09-18T05:35:39
URI is part of the core distributionIt's not part of the core perl distribution. It may be part of Activestate's distribution, but that's not the same thing.
Re:This one is sad
dws on 2006-09-19T03:09:26
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.Re:This one is sad
brian_d_foy on 2006-09-18T23:54:44
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 across the interface.
* There are no tests to go along with the patch. Specifically, tests have to ensure that the semicolon splitting only works on the query string and not anything else that might be in the URL. I don't think this is a problem, but a patch isn't a patch until it does the whole task.
* You simply can't change the behavior of an often used module and expect it not to upset a lot of people. When CGI.pm went to the ; by default, it broke scripts for some of my clients. I expect that a change to URI might do the same.
It's not as simple as adding a single character to a file. There's actually a lot of work that needs to happen to ensure thigns don't break, other software won't break because of the change, the interface stays consistent, and the feature works in the way it should.
So far, I haven't seen anyone who's step forward to do all of that.Re:This one is sad
dws on 2006-09-20T03:45:56
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.
Re:This one is sad
Aristotle on 2006-09-20T09:13:28
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.
Re:This one is sad
dws on 2006-09-21T18:09:55
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.
Re:This one is sad
Aristotle on 2006-09-21T20:49:40
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.
Re:This one is sad
dws on 2006-09-22T03:52:33
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
Re:This one is sad
dws on 2006-09-22T04:07:27
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.
Re:This one is sad
Aristotle on 2006-09-22T05:45:08
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?
Re:This one is sad
iburrell on 2006-09-23T22:48:00
Except that the ampersand does need to be escaped in some cases. "&foo=bar" is interpreted correctly only when the "foo" entity does not exist. This is a fallback. But ">=bar" is interpreted as ">=bar". This creates subtle bugs when HTML entity names are used. XHTML is more strict and does not have the entity fallback or the minimal format.The advantage of using semicolon is that a properly encoded URI is always valid HTML or XHTML and doesn't need to be escaped. The downside is that some tools, including the URI module, still do not handle ";" as param separator.
The problem with putting the HTML escaping in the URI module is that sometimes URIs are not going HTML. They get put into text files, email, or databases. And then get double-escaped or unescaped when converted into HTML.
Re:This one is sad
bart on 2007-06-03T09:39:24
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&b"> is "a&b". At least, that is how I understand it.
Re:rollup
jk2addict on 2006-09-18T12:57:03
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 big time when Lyo Kato (FormValidator::Simple) responded to emails but never updates RT. Had I had to hold off getting Handel out the door because of it, I guess I would be a little snippy too.Re:rollup
Matts on 2006-09-18T13:38:46
What's interesting is it's very rare for people to realise that they can "fix" the bugs they find by subclassing if it's that urgent. Admittedly it's not always the case, but when it is, it's often more appropriate than getting annoyed at the author.Re:rollup
brian_d_foy on 2006-09-19T00:06:34
Indeed, I'm devoting an entire chapter of Mastering Perl to dealing with absent module maintainers. I certainly know the pain of many approaches:)
Re:rollup
iburrell on 2006-09-18T15:34:48
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.Re:rollup
Aristotle on 2006-09-18T18:26:38
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.
Re:rollup
brian_d_foy on 2006-09-18T23:56:32
In the one case you cite, Gisle, the author or the module, did respond initially.
