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)
