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 ]

ChrisDolan (2855)

ChrisDolan
  (email not shown publicly)
http://www.chrisdolan.net/

Journal of ChrisDolan (2855)

Friday September 22, 2006
01:10 AM

PPI, and on being a contributor

[ #31077 ]

Today Peter Guzis made some cool new contributions to Perl::Critic. However, both of his new policies required patches to bugs in PPI to function. So I fixed them (thanks to a commit bit from AdamK). And kept going and going. I had fun digging into the PPI source code and fixed about a half-dozen bugs today.

This reminded me of a revelation I had about a year ago: sometimes it's more fun to be a contributor than a maintainer. As a contributor, one has the freedom to pick a small part of a project, learn it and improve it without having to worry about the whole. And then you can put it down and go to work on something else for a while.

So this week for my few precious free hours, I've chosen to work on PPI::Token::Number instead of Perl::Critic itself or on my own modules that need some work (e.g. FLV::Info -- apologies to Christian Donhofer who's waiting on a hard fix in that module!)

Another nice thing about being a contributor is that your energy can be contagious. I've noticed that most every time I commit a patch to PPI, Adam commits a patch or two shortly thereafter. The same holds for submitting patches to RT. Sometimes when I submit RT bugs, the maintainer fixes not only my bug but a couple others at the same time. That makes me feel like my contribution has a multiplier effect. Sweet!

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.
  • ... not all of them are reverts! :)

    But one thing I will note, if there's anything that's likely to spur me into fixing a bug, it's a test case.

    Because doing the diagnosis and writing a test case is often two thirds of the work (and most of the mental work). You don't have to break state very much or for very long to just fire up Devel::Pler>, walk through to the exact location of the bug, then twiddle the three or four lines needed to fix it. [cpan.org]

    In almost every case, particularly if you wrote the code in the
    • Grr... I hate not being able to edit comments :)
    • pler's pretty cool. I wish I remembered what problem I had with it.
      • Until the most recent version, it used to split the terminal improperly on Win32, because exec() doesn't work right on Win32. That's fixed now.

        But that's the only obviously problem I know about.
        • Nope, that's not it. Other people run Windows. I don't. The problem I had was I couldn't get the CPAN shell to install pler by the name "pler." Having to always name a module even for scripts isn't fun.
          • Hrm...

            I think I saw something in the Changes file for CPAN.pm that talked about improvements for installing scripts in a more sensible way.

            I'll keep it in mind though.