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



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)

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
postedOct 10, '09 at 9:10p
activeOct 10, '09 at 9:10p

1 user in discussion

David Golden: 1 post



site design / logo © 2021 Grokbase