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

[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

[EvanCarroll]

Well in my eyes it does address module abandonment and disputed functionality quite well -- it turns them into a technical problem, with a technical solution -- change the authority.

Maybe you're too immune to the current situation. Now users have to pick between modules of identical APIs, rather than identical modules with different authorities. I'm probably going to end of forking POE within the next month. I'm not sure what I'm going to call it, but I'm sure it will confuse people more than seeing POE<cpan:rcaputo> and POE<cpan:ecarroll>

[rir]

I recognize you here and I respect you, but without this thread I might not have made the connection between ECARROLL and Evan Carroll. I would not have placed rcaputo at all. I know I'm poor at tracking attributions but I don't see how a name like POE<cpan:ecarroll> is more informative than POE_Fast or POE_Portable.

Yes, I am relatively unaffected by any current namespace disputes. I am further removed from CPAN than you. For a decade or more, I used Perl for small jobs and when I discovered CPAN, the task, as a rookie, of finding a module to do some task lacked any immediate payback. It can be easier to build a wheel than to find one.

I am further removed from CPAN than you; I don't pretend to know the intent or workings of authorities. I seek education:

• How do I as user determine which POE is the POE I've heard about?
• Should I view the existence/publishing of both POE<cpan:rcaputo> and POE<cpan:ecarroll> as proof of some disagreement between the two authors?
• If not, how do I know which is the ephemeral package?
• If yes, how has the social problem been solved?
• If these authorities are of equal status, how should I not view this as the demolition of namespaces on CPAN? Update: My use of namespace here is vague, I really am referring to branding or product identification.
I do realize that more toolchain learning issues will deter people from contributing to CPAN. That is bad but does allow a smaller group the chance of greater cooperative action.

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?

[tye]

CPAN is already a mess. What we have now is 10 bugs not fixed and not reported because 10 people know darn well that the 80% of the time the only way to get a bug fixed is to take on the role of "stalker" in hopes of getting the lovely prize of "now you get to be the one that people are supposed to stalk", 4 different versions of each module with slightly different names and significantly different implementations and feature sets, none of which are getting improvements applied particularly well (most of the time) and none of which is the clear best choice just in terms of features. Short spurts of one person having the time to work on a module and then their life taking a turn and the module sitting untouched for years until somebody is actually perverse enough to jump through the hoop of "play stalker to the last person who touched it" for 6 months in order to be allowed to contribute to it (meanwhile, the module has been "forked" 3 times by people just starting over with a slightly different name).

Freedom and encouraging collaboration is scary until you do it. I'm a bit shocked that so many in the Perl community haven't overcome that fear. So CPAN will continue with its mini-empire building while a bunch of us put our modules on github and encourage collaboration and make it free for people to do the work of getting a module into shape for a new release and then releasing it. Eventually, freedom and collaboration will produce such better results that most of the CPAN mini-empires will just look sad.

There is no point in trying to explain this to the powers that run CPAN. They will just take it as a personal attack anyway. Instead, just act like the internet and "route around roadblocks" ("censorship" in the original quote).

Those who are invested in the closed-ownership and "we must have roadblocks to prevent chaos" will be scared and predict failure and may even be so close-minded as to feel threatened. Meanwhile, open collaboration will increase the pace of innovation such that it will stumble here and there but in the end will produce much better results.

I want to have the modules that I created and put onto CPAN in a "anybody can contribute" mode, but CPAN won't even allow me to do that. They don't support such "anarchy". Because we know that the concept of wikis were a passing fad that was simply doomed to a chaotic failure.

So don't waste your time trying to explain the better way. Just do it the better way and those who can deal will see the better way and use it. Those who fear contributions from others will cling to keeping their "ownership" (until they inevitably lose interest and their contribution withers and fades from memory).

Most open-source projects spend much of their lifespan being driven by a single developer. How well an open source project can support an orderly transition to the next community of contributors is a major factor in how long the project remains viable and useful. Allowing more Perl modules to much more seamlessly accept new contributors and transition to new owners will allow such modules to become mature (something that the vast majority of even useful modules on CPAN can't achieve). It will be a great benefit to Perl developers.

The policies of the CPAN services mean that CPAN is a huge collection of mostly just individual contributions where collaboration is the exception. We can do so, so much better. And we will!

[jettero]

You can assign as many co-maintainers as you like on pause. If you want it open, simply state that and then add people as they mail you. I really don't see what's so hard about that. In fact, it seems like about 12 lines of WWW::Mechanize code and you'd have an auto perminator on your web page. Then you could go to Hawaii permanently, end of story.

I rather with cfaber would have done that. He seems to have lost the permissions to the two yokels who have it now... and they won't respond.

If it were me, I would totally just assign co-maintainership, particularly if I didn't have time to work on it. And cfaber would have done so too.

[rir]

I don't think there is so much fear around as you think.

I want to have the modules that I created and put onto CPAN in a "anybody can contribute" mode, but CPAN won't even allow me to do that.

This is confused. CPAN is the Comprehensive Perl Archive Network and is well named (Ha, how I hope I am not walking into another backronym. ). If you have the right, you can develop a codebase where, how, and with whom you like, then you can release it on CPAN.

Licenses, established practice, and courtesy are arguments against summarily grabbing some author's code off of CPAN, reworking it, and putting it back on CPAN under the same name. It is not surprising that the CPAN admins are slow to declare code abandoned and then seize it.

Be well,
rir