Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Friday April 14, 2006
02:00 PM

Patches no longer welcome (I reckon we can do better)

[ #29327 ]

The space above 100 CPAN modules is a rarified one for authors, but a painful one.

The first author to reach it ended up so shocked and scared he ran away to God School to escape the pain.

And the second author to reach it, while warned about the pain, has had to start shedding modules to deal with it, and retreated back below.

The third (myself) and the fourth have I think only made it by cheating to a degree. In comparison to the two that preceded us, both Tatsuhiko and myself have I think released modules that are a lot smaller and modular. Lots of plugins for things, small extension, utility modules, and so on. Even the one big thing I've done is a collection of about 20 dists which are pretty small and modular (except for the main parsing module).

I know myself, I only survived by doing things in this componentised way, by trying to keep as close to a zero bug count in RT as I could, and by not releasing anything which wasn't at least basically done and working.

But I see the "CPAN Wall" approaching, and given my normal load at work, it's becoming increasingly difficult to maintain this many modules. The RT bug count is starting to creep upwards, and I'm finding less and less time to round them up and squash them. Using RT (or rather, any web-based bug reporting tool) isn't scaling any more.

But I don't see an end in sight for CPAN releases, there's still gaps to fill and itches to scratch, and I'm starting to ponder what the hell maintaining 200 modules might look like. *shudders*

So I'm going to make the same switch as the two authors that preceded me did, and see if I can lubricate maintenance a bit more.

So here's the deal folks (since I know some of the people reading this are the biggest bug reporters).

I'm still quite happy to take bug reports still, if you can't fix a problem yourself.

However, if you CAN fix the bug in a module I maintain yourself, I no longer want patches.

I've been converting my older unconventional CVS repository structure to a new shinier SVN repository with a more conventional package layout. As well as a great auto-release capabililty, it uses the awesome Insurrection SVN repository manager.

Anyone who has a CPAN login, and at least one uploaded bug-free module of their own, will be given full access to the repository to fix whatever bugs you need to. Then just let me know when you are done, and I'll press the shiny red release button and send it to CPAN.

This will hopefully greatly reduce the work needed by both of us to make routine bug fixes and have them released immediately, without requiring you to deal with the responsibility of taking the module over entirely.

No waiting for me to have a spare day for RT work, no uncomfortable questions from me about taking the modules over instead. :)

Fix your problem, and walk away.

To keep things simple, the accounts are linked to your CPAN email address.

When you need access, you should chase me down on IRC (prefered) or otherwise send me an email, and I'll turn on your account.

I'm greatly looking forward to this experiment in collective maintenance :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I have my own svn repository [bulknews.net] for my CPAN modules and other tools, and having to create accounts for bug submitters will be painful.

    We need fully functional FreePAN? Or use OpenID-like distributed authentication system for svn auth? (like using PAUSE authentication system to give a commit bit to my svn repository)

    • What's wrong with existing systems such as Open Foundry [openfoundry.org] and Sourceforge [sourceforge.net], both of which offer subversion repositories and account management?

      I'm guessing that you'd prefer to host and control the subversion repository directly, and merely want to out-source the account management side.

      • Yeah, you're right. The main reason I want to host myself is that I really, really want to use (and hack) Trac. I prefer Trac to other ticket/browsing tools like RT/SourceForge/ViewCVS etc.

        Slap me if either of OpenFoundry/SourceForge has a support of Trac yet.

      • I totally agree.

        I've tried SourceForge several times. The PPI family of modules are still in SourceForge, and are yet to be moved back in-house.

        But I find sourceforge overly difficult. The overheads created by their authentication system have driven away potential maintainers or patchers.

        In comparison with the way pugs works, I'm finding more and more that for every minute of effort required, you lose 10% of your potential maintainers (broad generalisation).

        I'm sick of saying "do you have a sourceforge acco
    • Well, firstly I expect the number of people to actually get an account, who are willing to go beyond just complaining and actually fix it to be low, a dozen or so.

      And also I'm only doing it this way because I think I've finally found something (Insurrection) that does things the Right Way, and with low enough overhead, that it will be easier than the alternatives.

      All the accounts are based on email addresses. So it's as simple as typing in an email address, and that's it. It generates default passwords, mai
      • Well, firstly I expect the number of people to actually get an account, who are willing to go beyond just complaining and actually fix it to be low, a dozen or so.

        I'd be surprised if anyone gets one, given that you said they must have a "bug-free" module.

        • That was a joke right?

          Because you've got two of them :)
          • Oh, so "bug free" means all the tests pass. :) (The tests don't cover much in my modules.) Thanks for clarifying. I had in mind...a couple authors on CPAN might have a bugfree module...
            • No, it means the module has an empty RT queue.

              Which obviously is a highly imperfect way of restricting people, but I'd like to set some sort of minimum standard.