calendarLancaster 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?
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?
version 6 saved on 12/04/13 16:13 by David Golden (xdg)
Home | Tags | Recent changes | History