CPAN Pull Request: Janaury done!

My first attempt in the CPAN Pull Request Challenge was the production of a patch listed here.

After a few days I asked the original maintaner to close the pull request, and then I submitted another one with the right set of commits here.

And it got merged!

Well, my pull request was quite small and, after all, easy. I would not define it entirely monkey-typing patch, but it is pretty much what I've done. And that is right to me: I'm not searching to demonstrate I'm a killer Perl programmer at the risk of breaking some well used module!

So what did I learn from my first pull request work?

A lot of things after all, and a lot of things that I should always keep in mind when collaborating to other projects.

The first thing is public embarassment: in my first pull request I did place a commit that was a wrong change to the module (see here). While doing it, I was sure that the original developers are smarter than me, but I was trying to simplify the code anyway and it seemed to me that using Exporter instead of an hand-written import method was the right way. But I was wrong!

And despite being wrong, I was teached an important lesson here: I should have checked outside of module (tests) to see who was using the import method in non-ordinary ways. And so I learned on how to use better grep.perl.org.

Another thing I learnt is that I should not produce more work for the original maintainer: each commit must describe well and in detail what the changes are, explaining also the motivations that lead me to such changes. This will be helpful for future referneces and discussions, and will speed-up the approval of the patch.

And of course, I re-learnt to use git branches. Each development should be made on a separated branch, and each branch should include only a set of related commits.

How did I worked on this pull request?

Being the module assigned to me quite simple (a single file), I started reading the source code and looking around for "well-known" problems. Warnings and hand-written import sounded good candidates for first fixes, and perlcritic can help at this stage. Of course, both of above do not require changes on a stable and deeply used module, so I had to throw away commits.

Then I read the documentation, finding that a few regular expressions were not matching what was in the docs, and therefore working around them to fix and to make the documentation coherent with the code. This is not simple and cannot be automated.

Each change was tested again the test suite, and here tools for test coverage can be very useful to find out other ways to improve the dist.

I'm happy to see I was able to produce a contribution, even if small.

And I'm glad to see I'm learning more and more things and methodologies.