Add any targets that you're aiming for during the hackathon.
Don't forget to put your name next to your entry.
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
Installed module database / Packlists replacement
Write a .packlist replacement, see this thread
Finish the Build.PL specification
CPANTS Kwalitee metrics
Implement some of the proposed kwalitee metrics
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.
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
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.
- 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
- 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.
- A UI to do single-shot result without being a CPANTESTER (H.Merijn Brand (Tux))
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/
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.
- 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)
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.
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.
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.
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/
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.
Proposed agenda and discussing notes have moved to LancasterConsensus.
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.
- 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)
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
Last modified: 12/04/13 06:42 by David Golden (xdg)