Re^8: Fixing broken CPAN modules without author cooperation (years)

[tye]

So, to be clear, salva, the most likely scenario seems to me to be: Bob sends you a bug report, either with a patch attached or, after you completely fail to respond in any way, a patch comes in as a follow-up to the bug report. After you (perhaps for the second time) completely fail to respond (for a few weeks) and you haven't gotten around to your queue of bugs for that module for "years" (as you said), Bob uploads an "unauthorized" version of the module with his patch applied.

I can't tell, even after all of the back-and-forth, whether that would leave you "very upset" (well, you said "very impolite and upsetting" so maybe the "very" wasn't meant to distribute across the "and" there).

Note that I don't consider any of the steps in my first paragraph to be particularly problematic. Quite the contrary, I find them to be the most likely results in general, not just for salva's modules. All salva has done is admit to being quite ordinary when it comes to interest in and level of involvement in a bit of software.

But I do consider responding to the above scenario with an actual display of being upset to be childish, counter-productive, and self-indulgent.

The correct response (IMHO) to the above scenario is to finally respond to the bug report(s) and to politely ask that the new volunteer/contributor consider taking advantage of their current level of interest in the module. The response would mention the git repo (why isn't that just in the module documentation?) and the backlog (that'd be good to put someplace public) and would offer to give the volunteer co-maintainer (at least) access, of course. The response or a follow-up would mention any suggestions about how to improve the patch.

Now, I can admit to the point that a polite action would be a 2nd (or 3rd) e-mail announcing (politely) that Bob (given that lack of response and years since the last release and at least implying that neither of those facts is surprising nor a bad reflection upon you) will soon be uploading a patched version of the module (and offering to seriously consider any concerns you might have and asking you to consider granting co-maintainer status so the upload won't remain "unofficial").

But I also consider that step rather optional. And my biggest concern with that step is that it stretches the time span from patch construction to publication of a patched release to the range where I find people are likely to loose their interest / motivation and then we'll just have two people with backlogs for the module and no fix published until "years" pass and one of you gets excessively bored or otherwise unusually motivated.

An obvious middle ground is for Bob to mention, when sending the patch, his intent to upload a patched version. That makes more sense if the patch comes after a bug report with no response. But I wonder if that would also be "impolite and upsetting" to you.

I think my balance point would settle upon two e-mails. If I sent a (full) patch in the initial bug report, then I'd not initially mention my intent to upload a patched release. If I got no response after a week, then I'd follow-up with an e-mail describing my intent to upload.

But I think it would be more likely that my first bug report would not contain a full patch (more likely just a patch that fixes the problem w/o incrementing the module version, adding a test to cover the fix, and updating the documentation). But, after no response, if I actually still had the motivation to produce a full patch, then I think I'd just forward the full patch and, as politely as I could, note that I plan to upload a patched version.

And I seriously wish that I could declare that my CPAN modules are officially open for such contribution. I would really like to know that, if I got hit by a bus, my modules on CPAN could actually receive contributions that would (eventually) be fully indexed without requiring somebody find the motivation to stalk my non-existence for 6 months and then beg for manual intervention from the admins.

[salva]

You know, I am not a machine with a hard coded set of rules, I am a person, am so my thinking and feeling are fuzzy...

If somebody releases an unauthorized version of my modules without first trying to communice with me in any way, yes, I probably would get upset.

If somebody releases an unauthorized version of my modules after I have failed to reply to several mails from him, I would probably feel more guilty than upset.

But nevertheless, I still think that in that later case, he should had written me an email volunteering to take over the module (even if for a single release) because even if I had failed to reply to his bug reports and patches, I still would be willing to collaborate with him to take out that new release and, this is the important thing, everybody will win.

[tye]

Well, that's good to hear.

But nevertheless, I still think that in that later case, he should had written me an email volunteering to take over the module (even if for a single release) because even if I had failed to reply to his bug reports and patches, I still would be willing to collaborate with him to take out that new release and, this is the important thing, everybody will win.

Yeah, that's one route to go, sure. But I'm trying to get people to see it from a different angle as well.

It isn't particularly uncommon for me to find a bug in a module. If the module is one of the better ones (as far as I can tell) on CPAN for addressing the problem that motivated me to look at it enough to find the bug, then I'm likely to be motivated enough to investigate the bug a little in order to decide if it is something I can fix or can work around or it if is the first sign of more serious problems with the module. So quite often I end up coming up with a fix for the bug.

But I probably didn't download this module out of boredom. I was trying to solve a programming problem. And that programming problem is likely a much bigger motivation for me than fixing your module. And, sure, I understand the benefit of open source and so I want to and try to contribute (and do contribute quite a bit).

But if fixing your bug goes from reporting the bug and a way I saw to fix it to waiting for a response, not getting one, still being motivated and seeing that the fix is generally useful and so doing all the detail work (adding a test, maybe updating some docs), then I'm probably starting to have a hard time finding the time and motivation to come back to this diversion again and again.

Expecting me to launch into a cold-call e-mail request to collaborate with you to produce a new release of the module by taking on the myriad little things that you think should be in the next release but have been enough of a headache to have managed to prevent you from actually producing that next release... Well, I'll likely realize that if I spend that keyboard time and calendar time working around the problem, then I have a much, much lower risk of the whole effort being for naught just because the last person to upload the module doesn't play well enough with others (or just continues to not respond or...). But releasing the bug fix would probably be the better route for all in the long run. If only I could expect that the odds were actually high that a bug fix would be released if I went down that route. That isn't my experience.

If the module hasn't seen an update in more than 6 months, then I think that a new, unofficial release which contains a fix to a bug is likely one of the best things that could happen next. It demonstrates that somebody found the module useful enough to bother fixing a bug in it. It might actually motivate even more updates.

If the module has had a recent release (official or not), then I'm more likely to just report it (to anybody who has uploaded recently) and expect somebody still has some motivation.

I have quite a few modules on CPAN (and quite a few planned). Fairly often I find some time to try to work on them. Most of that time of late ends up in my work to organize a whole bunch of different sources of changes into a public repo. Quite a few modules that I've uploaded have been updated by others since my last release. Most of my modules have a backlog of improvements. While I muddle around trying to put together a "next release" and put unfinished improvements into (public) branches, I'm glad that others lost patience and got me to jump through the hoops to allow them to become just one more person who is allowed to actually contribute "officially".

It is somewhat annoying for a new release of one of my modules to add another change set. But since I'm talking about encouraging such to happen no more than twice a year per module, the annoyance is quite minor and is my fault for not putting something out sooner. And it is far, far superior to the alternative of the change disappearing into my backlog that I haven't managed to make public yet.

I just feel bad for the other improvements that I never even see because people fail to go through the hoops to submit them in a process that has been shown to usually fail to produce results (for not-recently-updated modules on CPAN).

I have plans for most of my modules. The releases others have done of "my" modules have not really followed those plans (you think I have time to write up and publish my plans?). But had one been truly unfortunate, then I'd surely have been motivated to address it. In a perfect world, my grand plans would be carried out and the result would be another kick-ass module. But in a lot of ways, a functioning outhouse on the side of the road beats the heck out of a castle in the sky. And, in practice, the work people are motivated to actually do, usually ends up being decent work compared to the plans that I can't get finished, and a heck of a lot more useful.

[JavaFan]

I do not care whether the originally author of a module feels like.

But I do care about myself. I would never release an unauthorized version of a module under the same name. I don't find it not more than decent to use a different name. An author may be associated with a module. It may even bring him some benefits. Who am I to tarnish this, or piggyback on it.

It actually saddest me that there are people who think this ought to be normal.

[BrowserUk]

An author may be associated with a module. It may even bring him some benefits. Who am I to tarnish this, or piggyback on it.

So better that their name is associated with an out-of-date or broken module, than with one that someone found useful enough to consider spending time fixing and making those fixes available.

That is the most illogical reasoning.

[davido]

That's an excellent argument.

First, the author never loses his existing PAUSE directory. Granting co-maintainership doesn't mean that he will lose his autograph from the project. I would think that most individuals picking up co-maintainership on a module would be respectful enough to maintain credit to the original author.

I think that it speaks highly of an author's maturity and integrity when he is willing to recognize that his level of interest and ability to devote time to a project is waning. Handing off the baton to someone else with the talent, time, and interest is in the best interest of the module's user. Taking that action when the time comes is another feather in the author's cap.

[JavaFan]

Ah, but you're on a high horse where you think that what you consider to be outdated or a bug, is considered so by other as well. I do realize that what I consider a bug, may not be considered a bug by someone else.

As for not making fixes available, I don't get it. Is it impossible to make fixes available in any other way than to release a module with the same name?