Discussion agenda
Please don't schedule stuff yourself. If you have ideas, add it to the parking lot list at the end. Thank you. – David Golden (xdg)
All discussions will take place around lunchtime so we can talk while we eat and not lose too much valuable coding time. Exact details will be communicated on Thursday morning.
Tentative schedule:
Thursday, April 16
Test::More roadmap
- Independent of any implementation, what rationales are there for changing Test::Builder?
- what are the problems of Test::Builder today?
- what distinct groups of users would benefit from these problems being addressed?
- how would they benefit? (Are there any preconditions to achieve these benefits?)
- what are the costs to these or other groups of changing Test::Builder
- what are the risks of changing Test::Builder and how could they be mitigated?
- given benefits, costs and risks, should Test::Builder be changed?
- If there is agreement on changing Test::Builder, does exodist's propose *design* achieve these benefits with the expected costs?
- If the *design* could achieve the desired benefit/cost tradeoff, is the specific implementation at hand suitable?
- If not, what specification changes need to happen and who will review and sign off these changes?
CPAN Security
- What are known weaknesses and risks?
- PAUSE
- CPAN
- BackPAN
- Possible remedies?
- Fix PAUSE password length/storage?
- SSL for CPAN? For BackPAN? (Pinned certs in CPAN clients?)
- Eliminate mirrors and rely on central CDN?
- Central/SSL only for checksum files?
- Add per-dist checksums for BackPAN?
Friday, April 17
CPAN Governance
- Background, context and terminology
- Should we have a "Toolchain Charter" for toolchain modules?
- Setting and communicating direction: who, how, when?
- Checks and balances: direction changes, backwards compatibility, deprecation, deletion, dependencies, portability, broken releases, etc.
- Planning for possible maintainer absence and hand-off
- Oversight and "code review"? who, how, when?
- Toolchain charter adoption/promotion
- For toolchain modules → Opt-in? Mandatory? (Which modules – not all of PTG?)
- For "linchpin" or "important" modules → How do we approach their authors to consider something similar?
- PAUSE namespace adoption
- What criteria (if any) should PAUSE admins use to evaluate candidates for taking over a module?
- How should this differ by type of module (e.g. toolchain, "linchpin", "important" or other)?
CPAN Culture and Communication
culture: that complex whole which includes knowledge, belief, art, morals, law, custom, and any other capabilities and habits acquired by people as members of society
- What is the culture of CPAN?
- What do we encourage authors to do?
- What do we discourage authors from doing?
- Responsible kibbitzing practices (i.e. helping authors be better without annoying them); topics to discuss include:
- Mass bug reports (CVE/security/non-security)?
- Gamification?
- Metadata linting?
- "Preferred" modules (Kensho, "Moose uses it", alternatives, etc.)?
- Responsible forking practices (i.e. for when authors don't get better)
- Last resort?
- Public technical rationale? (pros and cons)
- Encouraging others to switch? (e.g. Everyone vs just your dependencies)
Saturday, April 18
PAUSE (non-security related)
- Draft a formal upload or indexing policy? (E.g. must have license to be indexed)
- Draft a formal takedown policy?
- Allow fast deletion?
- Require META file for indexing?
- Write PAUSE2 for -Omaintainable?
META spec
- Do we need a META v3 at all?
- Require 'provides'?
- Fix/clarify 'conflicts' prereq?
- Add 'breaks'?
- Formalize some 'x_' fields?
Toolchain interoperability
- How can compiler-detecters know about '--pp' without needing authors to change their Makefile.PLs?
Deprecating/dropping support
- Drop toolchain support for the single-quote separator for package names?
Sunday, April 19
- no discussions planned
Parking lot (topics to be scheduled)
- (your ideas here)
version 16 saved on 15/04/15 06:48 by David Golden (xdg)
Home | Tags | Recent changes | History
