Submitting patches and bug reports for modules via RT is the most important thing you can do, because others will be able to see your bug and patch there, no matter what the future fate of your contribution with the upstream module is. One possible solution for you is to also maintain a set of Distroprefs for CPAN and offer them for download via CPAN. That way, people can directly incorporate your modifications to modules into their build of CPAN. On the social side, please also see that an author does not always have the same priorities as you have, and if there is nothing to currently add to a bug report, a "thank you" note would surely be nice but is not always sent. A module author will always be a "single point of failure", but if you don't want a single point of failure, you hire multiple backups. If you think you've found a way around this without paying people to work on code, I'm sure people will look forward to hearing your idea. Personally, I doubt that any technical scheme, like requiring "two maintainers" will work. This will just make people "swap" maintainerships and not be more responsive to your requests.

More CPAN modules need to be hosted on revision-control-system repositories so that it is easier to submit patches and easier to produce releases after patches are applied. Although it may not seem like a lot of work to apply a patch and release a new version, it is certainly more work than it should be and this leads to authors being more likely to be blockers of new releases. I wish CPAN would ( place more emphasis on / pay more respect to ) progress and less on/to "ownership". Although the shift here would be rather subtle, I still think that it would help a lot to have the default be to allow new versions of modules to be indexed even if they aren't by an "authorized" author, so long as it has been a few months since an "authorized" author released a version. It shouldn't require manual intervention to allow somebody to release a new version of an abandoned module. If the "owner" objects, then they can become active and prevent such releases from being "official" (and thus prevent them from being fully indexed) by simply releasing every few months. If Joe Random Contributor can easily not just write a patch that fixes a bug but actually check in a patch and then check out a new snapshot of a module (and reconcile any work-in-progress that has not yet been released to CPAN), then Joe is more likely to feel like producing the full patch that updates the Changes file and adds appropriate unit tests (etc.). I've certainly refrained from producing patches for modules quite a few times because the black box (hole?) of "you have to submit it to the 'author' and hope they do something with it" often doesn't look promising. I have quite a few small patches to modules in various states at various places. From time to time I try to produce a new release of a module and usually find that the little details end up soaking up enough time that the release never actually gets finished and on CPAN before I'm pulled away for other tasks. Then, when I return, more little details have amassed (or been misplaced) and the same failure happens again. So I've started down the road of putting my modules into public git repositories. But, alas, that task is not yet completed either. It would be cool if CPAN (or, more likely, PAUSE) were to acquire such features (or at least to facilitate them), but we are all volunteers, of course... - tye

I fully agree with all of your points. (Except that I use svn instead of git, but that really doesn't matter). As long as the technical side isn't resolved, it might help to encourage people to hand out co-maintainership freely. It might help to have a wiki (or some such) where you can offer upload privileges, and list TODO items. For example I'm happy to help with Unicode handling of pure-perl modules. I'd just scan that list once a week, and see if there's something interesting. And when I work with a module anyway, I can just as well apply a few simple patches that live in the RT. Or I could just notice a module I'm familiar with, and accept co-maintainership to to decrease the response times to bug reports and patches. My experience with the pugs repository are very encouraging. We hand out commit bits very freely (when somebody say "I found a typo in file $file", the answer is usually "should I fix it, or do you want a commit bit?"), and so far haven't had any problems with vandalism or very poor commits. In any case I think it's important to try to lower the entry barrier for contribution to CPAN modules. Maybe somebody wants to write a Meditation on that matter (to increase visibility and to have a better title)?

Some notes below your chosen depth have not been shown here

Some notes below your chosen depth have not been shown here

I don't think hosting more CPAN modules in revision control would matter to most people or most modules. Although a small group of people will actually make a patch against the repository, most people don't. Even if a few people do patch against the repo, I've only ever had one person also update the tests. It might be hard for some hard-core contributors to realize that, but most people either don't have the time or inclination, and even more people don't have the skills to do it. You don't need anyone's permission to upload a new version of an abandoned module. PAUSE just doesn't index it if you don't have privileges. A restive period is not helpful because some modules don't need updates in that time frame. There's no timeframe that you can apply across of all CPAN. Don't refrain from patches because you think the author won't help. Make the patch public, such as in RT, and other people can get it even if the author doesn't apply it. Don't hide from the rest of the world what you know because one person doesn't respond to you. And, making the patch public starts the history of an author not responding to you and makes it easier for the PAUSE admins to see what happened so they can transfer the module when necessary.

brian d foy <brian@stonehenge.com>

Subscribe to --brian d foy Subscribe to The Perl Review

Some notes below your chosen depth have not been shown here

This is the point of http://svn.ali.as. I've put DBM::Deep in there and will (at some point) get the rest of my distros in there, too. I'm also an admin there, if anyone wants a committer bit. But, yes, it would be nice to have both svn.cpan.org and git.cpan.org available. I wonder what it would take to get that up and running? My criteria for good software: Does it work?





Can someone else come in, make a change, and be reasonably certain no bugs were introduced? My criteria for good software:

You make it sound as if the author owes you something. CPAN is a volunteer operation, people donate code in the hope that it will be useful. Yes, it's rude not to acknowledge a bug report or patch, but there are any number of reasons: people may be too busy, the e-mail forwarding address may be obsolete, the author may have lost interest. It takes discipline to manage CPAN modules correctly and so it's only natural that there's a certain amount of attrition over the years. If you have made a concerted effort to get in touch with the author (and ranting on Perlmonks doesn't count), can show that you are able to close out most, if not all, bugs on the RT queue of the distribution, then send a message to module-authors@perl.org documenting this, and you will be granted co-maint status on the module. This happens all the time. • another intruder with the mooring in the heart of the Perl

You make it sound as if the author owes you something. If so that is completely unintended. It is quite the opposite - I recognize the huge volunteer efforts put into CPAN. I'm just wondering if there are ways to improve how CPAN works so that it is less dependent on people being not busy, email accounts correctly set up, and maintainers still having interest in the modules they once wrote. If you have made a concerted effort to get in touch with the author (and ranting on Perlmonks doesn't count), can show that you are able to close out most, if not all, bugs on the RT queue of the distribution, then send a message to module-authors@perl.org documenting this, and you will be granted co-maint status on the module. This happens all the time. That's true. But not all of us are able to fulfill all those conditions. Most of us can make reasonable efforts to contact a module owner. Some of us can submit patches to modules. Very few of us has what it takes to step up and claim (co-)ownership of a widely used and fairly complex module. I certainly don't belong in the last category, I'm simply not that skilled. But I still want to contribute. I will try to be more patient from now on. --

No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

A few years ago I wrote about this in Responsibilities of a module author. I think it still holds true today. It would be ideal if authors were more responsive, even to say that a patch or bugfix isn't a priority. Unfortunately, not everyone is. I hope you won't let a few bad experiences color your perceptions. When I've encountered this in the past, after a few months, if it's a problem I'm really motivated about, I send the author an email asking about the status of the patch. If I don't get a response, I send a similar email once a month or so. (Not a long email -- like two sentences with a link to the RT entry.) In most cases, I've gotten responses back -- usually an apology for being too distracted to work on it. In other cases, somewhere between three and six months or so, I've offered to release the patch as a dev version if the author would give me co-maintainer rights. And I continue to make that offer every couple months. (That's how I wound up inheriting a number of modules, I'll admit.) Some people may say that this is too much harassment, but I don't think a 2-sentence email once a month is inappropriate. I'm a "customer" -- albeit for a free product -- and some responsiveness, even to say "I'm not going to fix that" is a reasonable expectation, I think. Obviously, if the author says "go away, I won't fix that" then I wouldn't pursue it, but that hasn't been my experience. Usually authors are just legitimately busy with @life and $job. If I get no response to any of these emails, then I'll try other ways to contact an author and if that fails, then if I'm still motivitated, that's when I think it's appropriate to appeal to the PAUSE maintainers for co-maintainer rights. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

As the author of many CPAN modules, I would be thrilled to have this sort of reminder. Fortunately, if people actually read my module docs and do what they say (put request in RT), I can review them later when I have time and interest. However, if something is important to you, reminding me once a month or so is definitely not a bad thing.

6 months is not a long time for an open source project me thinks. For example if your country has a Mandatory Military Service law, then you'll not be doing anything for at least 6 months (in Turkey this is upto 15 months if you did not graduate from collage). So, yes you can not know what the module author is dealing with. He can be ill, can have finance probs, $work can take all his/her time, he/she may even be dead (eg: Nick Ing-Simmons) I think it's better to ask for co-maintainership if you think that the bugs are really critical and you can even take full control over a specific module if the author is abandoned it (I abondoned a module and gave the maintainer rights to someone else for example). Another option is asking a co-maintainer permission from PAUSE admins (you are not Andreas König right? :) if the bug is causing critical failures. I think this was done for Template Toolkit some time back... If none suits you, you can always fork it and re-create Abc.pm as AbcX.pm and apply the fixes / release to CPAN if the license of the original module permits this.

Please help me restore my faith in CPAN. Sorry, no can do. CPAN is just a group of people and there's no reason you should have faith in all of them! In fact, some of them aren't going to help you. (Yes self, I'm looking at you. You can be a terrible maintainer!) Instead, you should learn to have faith in particular CPAN authors. Some of them are fantastic - responsive to the most minute and superficial problem. Some of them aren't. But don't worry - CPAN doesn't have the single-point of failure you seem to think it does. If you have an improvement that isn't getting accepted you have an easy remedy - fork the code and release your new version. If the module is truly abandoned you can even take it over and release under the same name. Then you'll be in the position to inspire faith in others by your awesome example! Open source software didn't get where it is today by letting the inconsistencies of bad maintainers slow it down. -sam

There's no official channel for bug reports. I'm not sure what you submitted or where you submitted it to. Some authors use RT, some don't. It's not a single system. Three bug reports isn't a big number considering the size of CPAN and the number of reports that authors do reply to. All you know is that you got no response. Email is quickly becoming unreliable because people not only filter their own mail, but upstream portions are filtering mail too. You don't know if anyone got the message, if they got the message and ignored it, got the message and forgot about it, and so on. If you don't get a response, try another way. The PAUSE system (because we're really not talking about CPAN) does not have a single point of failure as you describe. Some modules have only one maintainer, but the system allows for multiple maintainers. The system can handle multiple maintainers just fine. This isn't a problem with the system. Look at Parrot, for instance. They have a different release manager every month. You don't want just anyone to upload any module. We'd quickly make CPAN useless as no one would know which version of a module to use. Do we use your version, or Joe's version, or Bob's version? Don't be too quick to change things because there is something you don't like. Anything new will have its own set of problems. You can always make local patches as the PAUSE admins figure things out. Next time, you might choose a better subject line for your patch. Instead of "minor improvement", which means to me as an author that it's not urgent and I can think about it later, actually say why I would apply that patch, "Avoid warning when $foo is undefined". Even then, minor changes like that sometimes don't warrant a new release each time, so some authors save up everything for the next release.

brian d foy <brian@stonehenge.com>

Subscribe to --brian d foy Subscribe to The Perl Review

Some observations, from my limited number of patches/bug reports on CPAN: 1. modules that are heavily used tend to have fairly good turn-around on bug reports & patches (which may just be because heavily used modules have more patches and bug reports). Case in point: DBD::mysql still has some outstanding unicode bugs, but AFAICT that's mostly because nobody can figure out a good way to solve them, and there is at least some discussion on the RT about them. (Note that DBD::mysql also gets a lot of "bogus" bug reports due to its not very robust test suite). The patches I submitted were incorporated in the next release (which took about a month and a half IIRC). 2. Some modules really only have a few users, and the author might have moved on. Authors of those modules (myself included) may not be very actively maintaining them. I try to keep Audio::LADSPA more or less up to date with bugs, but it can take a week or two before I can work up the energy to check out a patch or bug report on it. My schedule is pretty hectic at the moment and I can't really afford to spend a lot of time working on stuff that isn't directly related to my job during the day. "What should it profit a man, if he should win a flame war, yet lose his cool?"

I'm an unresponsive CPAN author and it's because I don't have time. I hit email bankruptcy a year ago and now only check my mail once every few months. Most things I just discard and never look at. This includes most messages about modules. I wish this weren't so but I simply don't have time to do on-going maintenance for things that aren't actively requiring my attention. I am nearly always easily found on IRC and I hand out PAUSE permissions freely. Perhaps next life I can be a good CPAN author. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

> I hand out PAUSE permissions freely.

>

> Perhaps next life I can be a good CPAN author.



You ARE a good CPAN author. You may not be a great maintainer (for completely understandable reasons) but if you RECOGNISE you can't maintain your code, and provide an easy to use mechanism for people to take over your work and continue, you've behaved in a responsible manner as the original author.



Any author that knows to lead, follow, or get out of the way is an excellent author.

...I am nearly always easily found on IRC and I hand out PAUSE permissions freely. Suggestion: set up your cpan.org email address with an auto-responder that says what you just said above. That's at least a step towards being a good CPAN author. :-) Much friendlier than having email black-hole. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

No, I'd need to have a server running somewhere that I could host that on. If we had CPAN project pages as an automatic feature of having a distribution, this might be trivial. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

I don't know what is your CPAN id - so I did not check - but do you inform about this in your modules documentation?