Perl wants you


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Perl wants you

  1. 1. Intro / Preface ● Augustina Ragwitz – Perl Developer since 2007 – First YAPC in 2012 (Madison) ● Currently at MediaMath in NYC (we're hiring) ● auggy freenode irc: mmmpork twitter: @mmmpork
  2. 2. Why Am I Giving This Talk? ● I just made my first contributions ● Share what I've learned ● Encourage y'all to contribute!
  3. 3. Perl Wants You!
  4. 4. Open Source Software is Free! ● But there is a cost...
  5. 5. Open Source Software is like Public Radio ● Ok, more like Public Access TV...
  6. 6. Pay your dues! Contribute! ● Or just do it cuz it's fun
  7. 7. Start Small ● GOAL: Get familiar with the patching process first! ● Small code patches ● Documentation ● Unit Tests
  8. 8. Remember... ● Working in a new code base requires context! ● Don't be intimidated!
  9. 9. Talk to the Community! ● A lot of communication happens on IRC ● If you're not familiar with IRC → ● Server is ● Check documentation for irc channel info ● Or ask in #perl-help or #p5p
  10. 10. Where can I contribute to Perl? ● Any module on CPAN is fair game – ● Perl core is managed through P5P (Perl 5 Porters)
  11. 11. Perl Core (Perl 5 Porters) ● ● p5p mailing list – ● irc channel: #p5p on
  12. 12. Get your name in it! ● Pumpkings – a rotating group of individuals responsible for cobbling together changes nd releasing new Perl versions ● Patches go into new versions of Perl ● Submit a patch and get immortalized! – Your name goes into the release doc
  13. 13. Wow that sounds cool! Sooo, now what? ● Look for things that are easy to contribute! ● Easy = small fixes for learning the patching process
  14. 14. Easy Contributions ● Perl Core != C programming ● Documentation ● Patch supporting scripts ● Improve unit test coverage ● Some bugs are tagged in RT ● Check the todo list:
  15. 15. How to contribute to Perl Core ● Pretty well documented here - – ● Perlbug + tips – ● And here's a short walkthrough
  16. 16. CPAN ● The Comprehensive Perl Archive Network ● AKA the place where modules live ● Basically, an index that maps a module name to a file archive location ● - provides additional metadata not found in
  17. 17. PAUSE ● Perl Authors Upload Server ● Where the file archives live (that CPAN points to) ● Anyone can get an account – Only really need one to upload an archive ●
  18. 18. CPAN Testers ● Goal: Test CPAN modules with as many versions and configurations of Perl as possible on as many platforms as possible ● ●
  19. 19. What should I contribute to CPAN? ● File a bug ● Improve documentation on a module you struggled to use – Especially if you got help from the author! ● If you had to make local changes to make it work, submit the patch!
  20. 20. Alright, that sounds good! How do I get started?
  21. 21. Disclaimer ● All processes demonstrated here are my preference – TIMTOWTDI FTW! ● Module maintainers will have their own preferences. ● Check with the maintainer before following these steps to submit a patch.
  22. 22. Submit a Patch to CPAN ● You need the following: – The location of the source code repository – Where the author wants patches submitted
  23. 23. Find the Repo ● Some modules on Metacpan have repository info ● Check Module documentation ● Git::CPAN::Patch ● Download the source tarball (last resort)
  24. 24. Where to Submit the Patch ● GitHub, BitBucket, SourceForge... if the author has specified the bugtracker ● Otherwise, use RT
  25. 25. RT ● ● Send email to bug-acme- ● Use RT if: – The author says to, or – You can't find any bugtracker info in the module ● You can attach your patch to the RT!
  26. 26. GitHub ● ● Pull request is probably sufficient for submitting your patch ● Optional: Create an RT ticket
  27. 27. How do I write a patch that's likely to get merged? ● Don't submit a large complex patch ● Each issue should be its own commit ● Each commit should have a clear commit message ● Be consistent, stick to the author's style ● Update documentation when appropriate ● Write tests to support your changes ● Include a changelog entry
  28. 28. OK so how do I submit my patch!? ● Download the source code ● Make your changes ● Submit the code
  29. 29. What happens when I submit a patch? ● If the author accepts your change, they merge it into their repository and release the code! ● If your change is rejected, the author will comment on the pull request or the RT ticket – Don't give up!! – Talk it out with the author – Use the feedback to fix your patch
  30. 30. How do I know my patch was submitted? ● RT responds with an email – If you don't get an email, wait a couple of days and resubmit ● GitHub shows your pull request – If you don't hear anything, submit an RT ticket
  31. 31. What if the author doesn't respond, at all? ● Send email to – Use this resource after several attempts to contact the author – State a log of your attempts to contact the author – If the author is unresponsive, you could end up being the maintainer ● Fork! – This is Open Source after all...
  32. 32. Collaboration is fun! ● Fun to work on interesting things! ● Get others excited about your ideas... or get excited about someone else's! ● Good feeling to help out others ● Learn new things about programming! ● Even people who aren't using Perl at work contribute because it's FUN!
  33. 33. Q&A