Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

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

by jettero (Monsignor)
on May 16, 2009 at 20:44 UTC ( #764450=note: print w/replies, xml ) Need Help??

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

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.


  • Comment on Re^2: JETTERO tries to take over Net::IMAP::Simple on PAUSE

Replies are listed 'Best First'.
Re^3: JETTERO tries to take over Net::IMAP::Simple on PAUSE
by EvanCarroll (Chaplain) on May 18, 2009 at 05:22 UTC
    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.

    Evan Carroll
    The most respected person in the whole perl community.
      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,

        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>

        Evan Carroll
        The most respected person in the whole perl community.

      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?

      Enoch was right!
      Enjoy the last years of Rome.

        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!

        - tye        

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://764450]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2018-05-25 23:41 GMT
Find Nodes?
    Voting Booth?