CPAN PR Challenge: May done!

In order to recover from the April failure, I decided to do my May assignment as quick as possible.

And just a few days after I was on Mouse I placed a Pull Request:

As you can see I'm still doing more a clean-up refactoring, and this allows me to improve my Perl skills and learn about the module I'm working on. By the way, I tried also to fix up an official issue.

CPAN PR Challenge: April skipped!

I totally missed the April assignment.
I was assigned to Net::Pcap, that was definetively too much complex for my skills.
And besides, I did not have even time to study it in deep.
Sorry guys.

CPAN Pull Request Challenge: March done!

Even if my March PR was not very complicated, it was succesfully merged on time for my issue.

I have to admit that, due to personal duties, I was not able to contribute very much to the last assignment. So I applied the Perl way of doing it to the existing code resulting in removing a few unnecessary statements and conditions to the module.

Enough to keep on contributing to very good code and stay tuned in the Perl world.

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.

My first (tiny) pull request

So I spent a few hours studying my first module, the Test::Pod, and produce a few commits to make some small changes to the existing code in order to improve it (or at least, I hope so). The pull request can be found here.

Despite these small changes, I'm detailing here the approach I will try to use as a checklist during the challenge, in order to make it a path for learning and for not-breaking things:

• run all the tests in the distribution, in order to see if there is any failure (it should not be), and if so, start from such tests;
• search for open issues/tickets, and see if any of them is good for work on;
• read the dist documentation, see if it contains typos and/or errors and/or missing parts;
• read the code and see if there is something obvious that can be improved (e.g., use strict);
• inspect the code and see if it does what the documentation says.

Of course, it is required to iterate on each step and, of course, to test every single change against the test suite (and maybe provide a new test for that). 

It is important to not produce work for the original author, and therefere:

• do not change code only because I would have written it with a different name, logic, conditional or alike. Try instead to make code more concise keeping readibility;
• do not provide code that breaks and test every single change at least for what it is possible and for what is the understanding of the problem and of the language;
• commits must have a good description of every single change, so that the original author can understand what was the intention of every change;
• keep commits as small as possible.

I'll refine the above checklist as I go on the challenge.

In the meantime, a few utilities can help in the work, most notably perlcritic, perltidy and Devel::Cover and Devel::NTYProf or similar.

2015 CPAN Pull Request Challenge

I'm going to participate to the 2015 CPAN Pull Request Challenge, an effort to make developers join the Perl community and contribute back some code.

The idea is simple and beautiful: each month you are assigned a random CPAN dist and have to inspect, study, read it and propose something (a pull request) to improve it. It could be a bug fixing, ticket issue, code optimization, documentation, and so on. Everything that can be accepted back from the original author.

I'm a little nervous: it has been a lot since I do not program day by day using Perl, but I'm quite happy to have the opportunity to learn something from the masters and, most notably, to contribute stuff back to this great community.

Let's see wat will happen!