Dual-license your content for inclusion in The Perl 5 Wiki using this HOWTO, or join us for a chat on irc.freenode.net#PerlNet.

Melbourne Fail 100 Project

From PerlNet

Jump to: navigation, search

You need not have any experience in debugging, working with CPAN, using these modules, testing in Perl or any of those kinds of things to participate in this event. One of the aims of this event is to help you learn these skills.

The idea is that we're going to take a few modules from the top 100 fail list that Adam Kennedy has put together and see if we can fix any of the bugs. The list can be found at:

      http://ali.as/top100/  (see the FAIL 100 tab)

Click the module name to go through to the cpan distribution page and then to the testers reports to see what kinds of tests are failing and on what version of Perl and on what operating systems. The bugs we are able to fix depends on us being able to reproduce them.  :)

Suggestion is that we work in teams of 2-4 people so that we can share our knowledge of testing and debugging. If you have a particular module from that list that you'd like to try to work on, please nominate the following:

      Module name
      Module version
      Platform
      Perl version

Please note the information below


Next proposed date -- 9/Sept/2009

Notes

Possibly useful -- Git CPAN Patch


Adam Kennedy suggested potential modules in need of bug-squashing. If you look at the *Volatile 100* (not the FAIL 100) list at:

      http://ali.as/top100/

You'll notice there's a big plateau which then drops off. That plateau are essentially the modules used to install code from the CPAN. If they fail, then everything is broken downstream. Triaging bugs in that list in particular would go a long way to making everything else work better.

"Bugs" will tend to fall into one of three categories:

      * A real bug
      * A false positive that can be fixed
      * A broken system

The third ones we can't do much about, but the first two we can. Real bugs can potentially be patched, and false positives can often be worked around (you're on X which acts funny with Y, we'll skip tests Z). We can triage bugs without needing the systems they appear on, which makes things easier from an architecture standpoint.

Adam also suggested three modules in the FAIL 100 that are known to be in need of attention (as at Sept 2009):

* FCGI
* Test::Class
* List::MoreUtils (requires C programming skills)

Teams/Projects

Repo Locations

User:Alecclews will be on GitHub

TobyCorkindale will use GitHub

bsb @ GitHub