Thank you to everyone who has commented so far. I'm very pleased that
within 24 hours, we seem to have an emerging consensus (agreeing or
opposing) on most proposals.
For each proposal listed below, I'm summarizing my take on responses on the
mailing list. It's a bit subjective since some responses are "+1 if ...".
I've added a bit of commentary as well to help me keep track of the flow
of the discussions.
#--------------------------------------------------------------------------#
Formatting and Schema
01. Update the YAML version declaration
Consensus opposed (in favor of 02 instead)
02. Formally switch to "YAML Tiny"
Consensus agrees, but with general assent to deprecate YAML for JSON,
but specify YAML::Tiny as the legacy format anyway
03. Deprecate YAML Tiny dialect for JSON
Consensus agrees.
04. Formalize allowed version number formats
Consensus agrees. I note that alpha semantics need to be decided.
05. Schema
Consensus is this is "nice to have", but more interest in a validation
module over formal schema in the spec.
06. Data structures, not YAML
Consensus agrees, though clarifying that only the *spec* should be
in Perl data structures. Actual serialization should be described
elsewhere.
#--------------------------------------------------------------------------#
Prerequisites
07. Enhance granularity of prerequisites
Consensus agrees.
08. Extensibly Group Prereqs
Consensus agrees.
09. Clarify intent of 'recommends' and add 'suggests'
No consensus as proposed; discussion of alternative terms
10. Add a free-text prerequisite field
No consensus; opposition has stronger voices
11. OS/arch/platform-specific requirements
Consensus opposes
12. Allow Sequences (Arrays) for Prereqs
No consensus; approval has stronger voices; unresolved details over
*usage* of prereqs specified as arrays versus hashes
13. Add a post_depends set
No consensus
14. Prerequisites should be mutually exclusive
Consensus opposes
15. Add development_requires
No strong feeling one way or the other; seen as linked to 08
16. Binary Package Dependencies
Consensus is opposed, largely on challenge of doing it "right"
#--------------------------------------------------------------------------#
Change or clarify existing fields
17. Better formalization of license field
No consensus; some discussion of implementation alternatives
18. Make dynamic_config mandatory
Consensus is for mandatory dynamic_config OR optional "static_config" with
no clear consensus for one or the other
19. Make repository resource a hash
Consensus agrees, with debate over keys of repository data structure
20. Make bugtracker resource a hash
Consensus agrees
21. Formalize optional_features
Consensus agrees that 'optional_features' needs work, with debate over
formalizing along the lines of 08 or removal
22. Clarify author field
Consensus agrees that clarification is needed; no consensus over what should
be done
Add new fields
23. Have a "development version" flag
Consensus agrees, but issue may be redundant with 24
24. Add a "release_status" field
Only a few response and only mild support
25. Controlling test suite runs
No consensus; stronger voices opposed
26. Specify a DLSIP resource
Consensus opposed, though noting that DSLIP could be generated largely
from other META fields
27. Long description
Consensus agrees.
28. Short description
Consensus opposed.
29. Language
Consensus agrees, but with objections raised to 'perl5' as default value
30. Trove-Like Categories
Consensus largely opposes as proposed. Some interest in providing free-form
keywords instead.
31. Version changes
Consensus opposed
#--------------------------------------------------------------------------#
Other proposals
32. Steal from other package meta specs
Consensus opposed (on the grounds that it's not really a proposal)
33. Install Meta files and make them queryable
Consensus agrees, with concerns raised over overlap with packfiles
34. Formally reserve keys for private 'in-house' use
Consensus agrees, with preference for [xX]- prefix used consistently
throughout (and removing case for private keys for resources)
