Let me roll up replies to several items in this one reply...

Some people may say that this is too much harassment,

I say that it is excellent evidence that the system is broken. If anybody has had to resort to such drastic measures as often as you appear to have, then the system is requiring way too much from people who have to fight it just to get a patch applied. And the fact is that quite a few of us know darn well that without such drastic efforts, there is a reasonable chance that some patch that we produce to a CPAN module will never get applied.

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.

Under the current system, most times when I have a patch for a module, I don't bother to submit it. And I've heard a ton of similar stories. So the fact that you see few patches being written has more do with most CPAN modules not offering easy and reliable ways to get a patch applied. Why bother to produce a patch when history shows that most of them will get ignored unless you start a personal vendetta?

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.

I'm not a hard-core contributor. I'm a lazy bastard. I don't have the time to try to track down and then to nag some guy who submitted some implementation of a cool idea to CPAN months / years ago. When I run into a problem with a module, I do have a bit of time to fix the problem. If there is a system in place that makes submitting that fix easy and also likely to be useful, then I'm likely to use that system. And the easier it is and more importantly, the more likely it is to actually be applied, the more likely I am to patch documentation or tests as well.

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.

Oh, no, it is much more than that. It also means that your module will be tagged with "Unofficial Release" in big red letters (at http://search.cpan.org/). There are probably even more important consequences with regard to using standard tools for downloading modules, but I haven't tried using any of those for quite a long time so I wouldn't know much about that.

A restive period is not helpful because some modules don't need updates in that time frame.

If a module needs no update, then why is somebody trying to upload a new version of it?! Your logic makes no sense. The time period isn't about "Oh, module X needs to be released every 3 months". The time period is about how long it is reasonable to wait for a module author to apply a patch and release a new version of the module.

It would still be a big improvement if the clock started ticking as soon as an RT was opened against the latest release of a module. But that would still squash the spirit that motivated the creation of the first patch.

The point is encouraging contribution. The point is trusting people to contribute good stuff while providing for ways to deal with the rare bad contribution.

If I haven't released a version of my module in months and PAUSE / CPAN has been changed then somebody uploads a new version of "my" module that sucks, then I can upload an even newer version and fix the problem. Then the "bad" contributor is locked out again. If they are a serial bad contributor, then they you have a situation where administrative oversight is worth doing and take their upload rights away.

I'd even be fine with the new version of the module being "unofficial" and unindexed for a period of time in order to give the official maintainer(s) time to respond to the upload. But it would be much more encouraging if the timeouts were automatic such that I could upload something useful and know that some person would have to make an effort to counter it in order to prevent it becoming official.

When I find a problem, there is usually a pretty short window of time over which I'll remain motivated enough to work on fixing the problem. About 90% of the time when I find a problem with a CPAN module, it is a module that hasn't been released in quite a few months. And if I'm interested in patching it (which happens surprisingly often), then that means that the module is of reasonable enough quality that I think it can at least be made genuinely useful.

So, if it were easy to create a patch, apply it, and release a new version based on it (rather quickly), then I'd just do it right then while I've recently worked out what needs to be fixed and whether the fix can fit in with the existing module or whether I just need to fork it or find a different solution, etc. Part of that process is evaluating whether the module is currently under active maintenance. If so, then I just submit to the maintainer. If not, then I should just release a new version right then.

If there is a repository, then I can see what maintenance has recently been done, even though no new release has been produced in quite a while. And I can even see that some other bug fixes have been applied and deal with / release those.

The point is to allow whoever comes along with the motivation to work on a module for an hour or few to find tools to help them to contribute usefully. They shouldn't find a system that values module ownership over all other considerations along with a system of red tape and long delays and appealing to the privileged cabal to deign to permanently annoint them with the burdensome tag of "I now maintain this module".

What a perfect system for crushing contribution.

CPAN is great for getting people to contribute new modules. It is also very good at getting people to not contribute to existing modules.

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.

Don't you love beaurocratic red tape? I guess if it is your own empire that you have built, then maybe you do. CPAN has become a little empire that allows people to stake out their own little empires within it.

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.

Like I said, I'm a lazy bastard. I have never grabbed a module, rooted around in RT looking for useful patches, downloaded the patches and tried to apply them, etc. That is way too much work. Heck, for many modules, I can implement my own replacement for it easier than that. So I'm quite unlikely to find appealing the idea of putting together a patch with the hope that it would be used as you describe.

You are correct that CPAN makes this about the best that can be done. And I encourage people to follow your advice. But I'd much rather that people have much better options.

The few times I've been successful at getting changes made to a module were the times I just wrote the author and said "make me a maintainer and I'll update it".

And even when they do that, I'm still not allowed to give co-maintainer access to anybody else. PAUSE/CPAN doesn't even support their being more than one person who can dish out permissions to upload "authorized" releases of modules. It is just sad (and frustrating).

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.

Heh. Yes, keep telling yourself that. The system it perfect.

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.

Note that I'll be encouraging people to use RT for reporting bugs even though my git repository has tools for bug tracking. RT is integrated with search.cpan.org (and PerlMonks itself recognizes it via the rt:// linking short-cut). If a module maintainer doesn't want bugs submitted to RT, then they should document how they want bugs submitted, of course.

If you don't get a response, try another way.

Yes, e-mail and then wait a week. If you don't get a response, then pretend you are stalking the person and try to find alternate contact methods. Oh, except that when that week is up you've probably lost most of your enthusiasm about getting the patch applied anyway. So make a new version of the module with a slightly different name and upload it to CPAN. CPAN likes it when you do that; they make that very easy.

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?

Yes, just look at Wikipedia. This whole wiki "anybody can contribute" idea is an abject failure. It is much better that we encourage everybody to upload new modules that solve the same problem but with a slightly different name. That makes picking between them so much easier. If we had just one module with several versions written by several different authors arranged as a linear progression, each based on the previous one, that would be terribly confusing and all would be lost.

You can always make local patches as the PAUSE admins figure things out.

And as your interest in fixing things drifts away and your enthusiasm for contributing to CPAN gets converted to disdain with each successive long wait for the unraveling of the red tape...