Re: JETTERO tries to take over Net::IMAP::Simple on PAUSE

[EvanCarroll]

Your post brings up a lot of cpan deficiencies -- management, the inability to fork into the same name-space, etc... I don't have a solution to your problem, I've had the same issues and in the past I've just hostilely forked into a different name-space to get the job done MooseX::Types::DateTime::ButMaintained. In the end, I hope cpan dies and gives way to something like http://github.org which allready supports this functionality and is making headway into Ruby with the ruby-gem autobuild system.
I for one vote you get the maintainership you're seeking without any more undue hardship, so long as you keep the already packaged version of this distro so people can find it if you break anything.

[jettero]

I think the current system works just fine. This is part of the process. It's easy for an active maintainer to keep control of a namespace and there is also a path to recover a namespace if necessary -- the nuclear option being: modules@. It makes perfect sense to me how it is. Nothing stops you from creating a similar namespace (with a x on the end or ::Plus, like I did) if you want to make a fork.

No changes required.

Also note that when you make forks on github (for example); you're making a brand new namespace every time too. It'd be much like if every module on CPAN was JETTERO::Net::IMAP:... though.

[EvanCarroll]

Just a few corrections:


Also note that when you make forks on github (for example); you're making a brand new namespace every time too. It'd be much like if every module on CPAN was JETTERO::Net::IMAP:... though.




That is pretty much wrong. Github, unlike cpan, does not tie the name of the perl package, to the working name in the index. Everyone can have a package Foo. So if this project was on github, and you forked it you'd have a unique namespace on github to develop and release changes all while maintaining the same *perl* namespace. The responsibility of integrating your chances goes on the *maintainer*.


Perl 6 will support this with authorities. So in your case, in p6, your CPAN authority would change from <cpan:cfaber> in the use declaration to <cpan:jetthro>. If more people see your package as authoritative, you can become the new (social not technical) central point.


What does this mean, well it all boils down to this: if your package is totally backwards compatible, but it has bug fixes, than by publishing it to a different perl namespace your hacking around a technical deficiency of CPAN/perl. The future holds a much better way. Even now though, without adapting perl5 to use authorities, cpan should support this -- the difference is because we don't have authorities your change would effect the whole install. So you should be able to publish to cpan under the same package, download the package from a different cpan-namespace, and then it would just silently and transparently effect all things that used that perl package.


I just wanted to try to sum this up clearer: the issue with cpan is you're not trying to release a *new* package, you're trying to patch and improve upon an old package. You're having to partake in a social obstacle that you shouldn't have to bother with: tracking down the author, convincing him your changes are better, getting him to release another copy or transfer maintainership. This is an endeavor you, as someone who is not new to cpan, might be willing to do; but I'm not sure that everyone is going to bother calling up companies to track down some old hacker.

[rir]

This sounds like a handy tool for cooperation between people developing CP6AN modules, but it doesn't seem to address the underlying problem of module abandonment or disputed functionality.

I question the validity of your last point. The "social obstacle" may not be removed. Someone new to CPAN, may find it easier to deal with the easily grasped "social obstacle" than to have another tool added to the toolset that he needs to learn. Note that another tool effects all contributors, while only some need to deal with these forking problems.

Hopefully, ordinary CP6AN users would not need to learn about the authorities choices. That will complicate their experience and give motive for the abuse of authorities to present users with a customized view of the aggregate collection which is CP6AN.

Be well,
rir

[Jenda]

This looks like a perfect opportunity for a huge mess. It makes forking way too simple. We'd end up with five to ten incompatible versions of the most common modules, most of them created by some know-all dudes and no way to distinguish between them within a script. And that's the less bad thing. We might easily end up with two incompatible, but both good versions of a module and other modules requiring one or the other version. And then sooner or later you'll want to use a module that requires version A and another that requires version B. How do you expect them to abide each other inside one script?

[Anonymous Monk]

Ever seen UNAUTHORIZED RELEASE on CPAN? That is forking. Instead of pulling from jettero's github, instead of downloading jettero's UNAUTHORIZED RELEASE, jettero wants to become the official release, so his release shows up in the module list.