Add any targets that you're aiming for during the hackathon.

Don't forget to put your name next to your entry.

Module::Build replacement

Write various components of a planned Module::Build replacement, including

• Finish the prototype, Module::Build::Tiny.
• Finish ExtUtils::Builder, a general purpose compiling/linking framework
• Write a dependency engine that doesn't suck
• Tie everything together and write the actual thing itself

By: Leon Timmermans (‎leont‎)

Installed module database / Packlists replacement

Write a .packlist replacement, see this thread

By: user:Schwern, Leon Timmermans (‎leont‎), Salve J. Nilsen (‎sjn‎), Joakim T (‎trmjoa‎) others?
See also: wishlist by Miyagawa, item 2 at https://gist.github.com/miyagawa/5205730

Finish the Build.PL specification

The Build.PL specification needs to be finished
By: xdg?, Leon Timmermans (‎leont‎), Salve J. Nilsen (‎sjn‎), Joakim T (‎trmjoa‎)

CPANTS Kwalitee metrics

Implement some of the proposed kwalitee metrics

By: Kenichi Ishigaki (‎charsbar‎), Olivier Mengué (‎dolmen‎) (H.Merijn Brand (‎Tux‎) and Salve J. Nilsen (‎sjn‎) are interested in giving feedback and user input)

Test::Smoke and Test::Smoke::Gateway

Now that the gateway works and is on-line and receiving since the last QAH, we
need to polish the UI and define some selection criteria that will help the p5
developers get in-depth analysis out of the stored data.

By: H.Merijn Brand (‎Tux‎), Abe Timmerman (‎abeltje‎)

Test::DBI or DBI::Test

Write a test suite or test framework that is to be used by both DBI itself and
all DBD's to test basic DBI functionality

By: H.Merijn Brand (‎Tux‎), Jens Rehsack (‎Sno‎), ribasushi +1

Test::Database

The module reached version 1.00 thanks to the QA Hackathon in Birmingham.

I recently found out that it's actually used by some projects, so it's certainly worth spending some time on improving it.

By: Philippe Bruhat (‎BooK‎)

CPAN.pm enhancements

• Finish internal logic refactoring work from Paris (xdg)
• Streamline CPAN mirror selection to use www.cpan.org, now that it's a GTLD balanced server supported by Perl NOC (xdg)
• Continue new index implementation work from Paris (xdg)
• Add policies and support for Recommends and Suggests

By: David Golden (‎xdg‎), James E Keenan (‎kid51‎), Elizabeth Mattijsen (‎liz‎)
See also: wishlist by Miyagawa, item 3 at https://gist.github.com/miyagawa/5205730

CPAN Testers

• Pending availability of donated servers, migrate Metabase off AWS (xdg)
• Finish up the git-based test result storage and convince xdg it is superior to anything else he is working with (ribasushi)
• Finish up the CPAN Testers Admin site to manage bad reports & testers.
• Write the interfaces to MongodDB for the new Metabase.

By: David Golden (‎xdg‎), ribasushi +1, Barbie, Elizabeth Mattijsen (‎liz‎)

Show some sweet, sweet love to Test::Harness

I have three main targets for this hackathon, all surrounding Test::Harness. I would like feedback from people regarding which of the three targets is the most valuable so that I can better prioritize my time.

1. I intend to work on the bug queue for . Fortunately, many issues are merely annoyances and not actual bugs.

2. Parsing subtests. Tools built around the underlying TAP::Parser pretty much have to ignore subtests (except for the summary line). This should be fixed. Andy Armstrong assured me that this wasn't just a few minutes worth of work and I thought "naw, this should be quick." I was wrong. This is a non-trivial problem requiring two phases. The first is to parse the subtests. The second is to extend the event system to trigger on subtests, lest our code block until each subtest is finished.

3. Add --startup, --setup, --teardown, --shutdown switches to prove:

prove -lr --startup tools/create_db \
--setup   tools/refresh_tables      \
--shutdown tools/destroy_db         \
t/

By: user:ovid

Get Test::* all passing with Test::Builder 1.5

This is a focused effort to get all of the Test::* modules on CPAN working with Test::Builder 1.5.

The largest obstacle to releasing Test::Builder 1.5 is roughly 100 of 1000 Test::* modules fail when using it. Some are functional differences, but mostly these are small differences in test output formatting.

This will be accomplished by several means, many of which can be done by anyone familiar with writing tests.

• Fixing revealed problems in Test::Builder 1.5.
• Writing/improving a Test testing module which works across the 0.9x / 1.5 line.
• Patching the failing Test::* modules' test suite to work with 1.5.
• Possibly rolling back formatting changes in Test::Builder 1.5.

By: user:Schwern

CPANcover

• Review and update modules covered
• Think about allowing uploading of coverage runs
• Improve front end
• Create an API
• Integrate with metacpan
• Consider a dynamic Devel::Cover report (no static html files)

By: Paul Johnson (‎pjcj‎), James E Keenan (‎kid51‎), Elizabeth Mattijsen (‎liz‎) ; (ribasushi +1 is very interested in giving feedback and user input)

Smoke/tests with exact dependencies

I often have issues with module installs, where the dependencies declare they require $dependent-module version $N of which I have a slightly newer, but not the latest, version installed, and the tests fail. This seems to be due to new module releases not updating their dep lists to include "the version I last developed against".

I'd like to produce a tool with which we can test a distribution against "the exact versions of the dependencies given" and see if it passes, the results will be reported to CPANTesters. Hopefully this will encourage people to check their deps more often.

By: Jess Robinson (‎castaway‎)

Stabilise Test::Proto

Test::Proto works but feels more like a proof of concept at the moment, and the internal design needs a bit of a rethink.

1. Talk to other QA people about how Test::Proto works, revise specs as required.
2. Implement it.

Areas to focus on, depending on how far I've got by mid-April:

• Classes, Roles, Inheritance
• Exception Catching
• The results formatter
• SKIP, TODO, and tags

By: user:pdl. Also would like to spend some time helping out on at least one other project.

"Perl 5 specification" test suite

Build a test suite for the Perl 5 language based on the current Perl 5 implementation test suite, as a way for Perl5 forks and wannabees to test their level of support of their reference language.

A goal for the future is to be able to produce something like http://perl6.org/compilers/features. Maybe take inspiration from https://github.com/perl6/roast.

By: Philippe Bruhat (‎BooK‎), Elizabeth Mattijsen (‎liz‎)

Document CPAN Author/Toolchain best practices

Information about toolchain is scattered around various blog posts, modules, wikis and so on. A lot of it is dated. Some is written by people who don't know what they're talking about. If some sites every went down, we'd lose it.

David Golden (‎xdg‎) has created a repository to collect these scattered bits of information: https://github.com/Perl-Toolchain-Gang/toolchain-site

If someone wants a less code-intensive project, this one will involve interviewing attendees to get pointers to relevant material and assembling it into something cohesive.

By: David Golden (‎xdg‎) (coordinating only), Wendy Van Dijk (‎woolfy‎) (doing interviews and making notes, not doing any coding)

Devel::Cover work

Prepare a presentation covering some of the newer parts of Devel::Cover with James E Keenan (‎kid51‎)

Investigate using Mike Friedman's infrastructure to collect coverage data.

Look into getting regular, automated coverage for the core (as suggested by Nicholas). See also Abe's work at https://source.test-smoke.org/svn/buildgcov/

By: Paul Johnson (‎pjcj‎) James E Keenan (‎kid51‎), Elizabeth Mattijsen (‎liz‎)

Lancaster Consensus

The Oslo Consensus came out of the first QA hackathon and established some common practices to guide CPAN authors and toolchain devs.

We probably have a long backlog of issues and ideas and it would be great to get a new consensus. Maybe we can use lunches/dinners to bang this out. We need a volunteer to scribe the outcome.

Potential issues, including some things already listed as projects, since those probably require some consensus anyway:

• packfiles suck -- how do we fix/replace? (as above) - Final decision on .packfile replacement installation location.
• Build.PL spec -- are we done yet? (as above)
• Distribution names are not unique -- what do we do?
• Do we need a v3 META spec update cycle? If so, what are some starting proposals? (this could include documenting all the known x_ fields being used with META v2)
• Eliminate the module registration list?
• Automate PAUSE ID registration? (no human Turing test)
• Postinstall target and preinstall target, for installing custom post-install and pre-install package installation helper scripts (which are scripts used by RPM and DPKG to prepare or finish a package installation (for creating users, dirs, fixing permissions, etc.))
• Post-install tests! Final decision on where they are to be installed.
• Standardize "Pure perl only" build upon configuration? (--no-xs, --pp, --pp_only etc.)
• Using the "ADOPTME" PAUSE ID as comaint to flag abandoned dists
• ...

(Please feel free to add more):

By: David Golden (‎xdg‎) (coordinating), Elizabeth Mattijsen (‎liz‎), Wendy Van Dijk (‎woolfy‎) (offering to make notes of discussions and make a report), Barbie

A better BackPAN Index

Acme and Schwern built BackPAN::Index, but it doesn't do what we need most, which is letting someone look up what tarball could provide a package name of a given version. We need the "all history" version of the 02packages.details.txt index.

Goals:

• Create a mapping similar to 02package that associates every unique package/version combination on CPAN or BackPAN to a single, best tarball to provide it
• For each mapping, indicate whether it was "authorized" or "unauthorized" to the best of our ability, considering alpha version and permissions data (this will require heuristics)
• Create a database and module to query it
• Extra credit #1: Design a process to keep it up to date (possibly directly by PAUSE during indexing)
• Extra credit #2: create and host a web API for queries

Whatever it is could be added to BackPAN::Index or could be something new, whatever is easier to achieve. The first iteration "database" could be a text file or a SQLite database or whatever.

By: Matthew Horsfall (‎alh‎) (we hope)

Coaching/cheerleading: David Golden (‎xdg‎)

External Links

user:miyagawa doesn't attend QA hackathon this year, but he plans to have a satellite QA hackathon in Tokyo while he's there on 13th (day 2). His wishlist is available at https://gist.github.com/miyagawa/5205730

version 54 saved on 31/03/13 21:37 by Wendy Van Dijk (‎woolfy‎)

Home | Tags | Recent changes | History