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...
