Sponsors

Corporate

Donate to Perl QA

cpanel.net

dijkmat

DYN.com

Eligo Recruitment

Evozon

$foo Magazin

Shadowcat Systems Limited

Community

Enlightened Perl Organisation

Mongueurs de Perl

Lancaster Consensus

POST-HACKATHON UPDATE: Results posted here: The Annotated Lancaster Consensus

  • What: get group consensus and moral authority on various toolchain/QA questions
  • When: lunchtime on Fri, Sat, Sunday
  • Who: anyone interested

(Please feel free to add more items below)

FRIDAY: THE TOOLCHAIN

Minimum Perl version supported by the toolchain

Currently, it's 5.6.0. Schwern proposes 5.8.X. What should X be? Or should we jump all the way to 5.10.0?

Packlist replacement

People are working on a replacment for packlists, but there are open issues around how to deal with all the various places things can be installed.

Where should packlist replacment database(s) cover and where do they live?

Read How to Build a Perl Package Database thread for background.

Pure-perl builds

Can we pick a standard way to tell Build.PL and Makefile.PL to do a pure-perl (no XS) build? E.g.--no-xs, --pp, --pp_only or an environment variable?

The Build.PL spec

Leon is continuing to push forward a specification for Build.PL based tools. This is his chance to poll the group on open questions.

SATURDAY: PAUSE AND META

Non-unique distribution names

tl;dr: PAUSE knows about "Foo::Bar" and "DAGOLDEN/Foo-Bar-1.23.tar.gz". Other tools (RT, CPAN Testers, cpan search engines) pretend that "Foo-Bar" or "Foo-Bar-1.23" are unique, but nothing enforces that.

Gory details Distribution names are not unique.

What is the least-worst option?

META spec v2 bugs

Let's resolve any open questions:

  • The 'provides' field must have a 'file' sub-field, but what goes there for dynamically generated modules? It it actually useful for anything?
  • Other issues?

META Spec v3

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). E.g.

  • Add "contributors" and "authority"?
  • Get rid of optional features?
  • Get rid of 'conflicts'? (And replace it with something useful?)
  • Document MYMETA?
  • Allowed characters and encodings?

*Note* We aren't debating the answers, just seeing if we have a long enough and significant enough list to actually start a new RFP discussion process

Module registration is pointless

Should we eliminate the module registration list?

It's not terribly useful anymore now that we have search. Removing it is less volunteer admin work and would allow more PAUSE code pruning.

See this blog and comments for some thoughts on it.

"ADOPTME" and abandoned modules

We transfer primary to ADOPTME for deceased authors or for dists people "give up". Should we let the community flag distributions with non-responsive authors by proposing ADOPTME get co-maint (with the usual co-maint request rules)? Is the benefit worth the admin work?

Discussion here: flag abandoned dists

Automating PAUSE ID registration

IDs are manually approved. Other places like rubygems don't bother. Should we take the humans out of the loop? Is recaptcha sufficient? Do we need email-confirmation?

Cleaning CPAN

Should we delete non-indexed distributions older than X years and let them just live on BackPAN?

SUNDAY: TESTING AND ALL OTHER BUSINESS

AUTOMATED_TESTING vs non-interactive testing

Miyagawa asks for a better way to signal non-interactivity, since AUTOMATED_TESTING is also used to launch slow/expensive tests only on smokers.

See "Nobody is watching the tests" flag.

Pre-install and post-install

Should we have a standard pre/postinstall target for make and Build?

These would be 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.).

If so, what should the expectations/semantics be?

Installing tests

Where should post-install tests be installed?

There's been talk of installing a distribution's tests so it can be retested (e.g. sanity check after other modules are installed). If this ever is to happen, where should such tests be installed (presumably in @INC somewhere)?

Bus number

What parts of Perl/community infrastructure still have a low bus number and what should we do about it?

Last modified: 19/04/13 19:59 by David Golden (‎xdg‎)

Home | Edit this page | Tags | Recent changes | History