Grokbase › Groups › Perl › cpan-workers › November 2009
FAQ
The public discussion period for CPAN Meta Spec Proposals is now closed. I
would like thank everyone who contributed proposals, feedback and patches.
We received 34 proposals, which resulted in over 340 discussion emails from 23
people.

Of the 34 proposals, 18 had some degree of consensus and at least a rough
draft patch (or git branch) to use to revise the spec. Two more proposals
had patches but one was controversial and the other clarifies an existing
field in lieu of adopting the proposal.

All of these will now be merged into a single draft 2.0 META spec and
circulated to the working group for review and refinement. The working group
will finalize the new specification by December 1, at which point it will be
released as final and work will begin to implement the spec in the CPAN
toolchain and other downstream consumers.

Again, thank you to all who contributed. A summary of the results is
provided below. All of the proposed patches are also available in branches
at the github repository: http://github.com/dagolden/cpan-meta-spec

Sincerely,
David Golden

#---------------------#
SUMMARY OF RESULTS
#---------------------#

Some consensus and patch written:

02. Formally switch to "YAML Tiny" [patch by Ricardo Signes]
03. Deprecate YAML Tiny dialect for JSON [patch by Ricardo Signes]
04. Formalize allowed version number formats [patch by David Golden]
06. Data structures [examples in spec], not YAML [patch by Ricardo Signes]
07. Enhance granularity of prerequisites [patch by Ricardo Signes and
David Golden]
08. Extensibly Group Prereqs [patch by Ricardo Signes]
09. Clarify intent of 'recommends' and add 'suggests' [patch by David Golden]
12. Allow Sequences (Arrays) for Prereqs [patch by David Golden]
15. Add development_requires [patch by David Golden]
17. Better formalization of license field [patch by David Golden]
18. Make dynamic_config mandatory [patch by David Golden]
19. Make repository resource a hash [patch by Ricardo Signes]
20. Make bugtracker resource a hash [patch by Ricrado Signes]
21. Formalize optional_features [patch by David Golden]
22. Clarify author field [patch by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯]
24. Add a "release_status" field [patch by David Golden]
27. Long description [patch by David Golden]
34. Formally reserve keys for private 'in-house' use [patch by David Golden]

Controversial, but patch written:

29. Language [patch by Ricardo Signes]

Not adopted, but patch written to clarify existing, similar field:

30. Trove-Like Categories

No consensus or consensus opposes or duplicative or other reasons for
not including in 2.0:

01. Update the YAML version declaration
05. Schema
10. Add a free-text prerequisite field
11. OS/arch/platform-specific requirements
13. Add a post_depends set
14. Prerequisites should be mutually exclusive
16. Binary Package Dependencies
23. Have a "development version" flag
25. Controlling test suite runs
26. Specify a DLSIP resource
28. Short description
31. Version changes
32. Steal from other package meta specs
33. Install Meta files and make them queryable

Search Discussions

  • Adam Kennedy at Nov 2, 2009 at 11:00 pm ⇧
    Ack, it would appear my comments on the proposals are late by 5 minutes or so.

    Please ignore, I shall move my additions (particularly the counter
    consensus additions) to the Spec review once it arrives, since most of
    my problems with this set of features are along the lines of "This
    feature has not be sufficiently specified, and the behaviours have not
    been defined properly or cannot be defined properly".

    Adam K
    On Tue, Nov 3, 2009 at 9:42 AM, David Golden wrote:
    The public discussion period for CPAN Meta Spec Proposals is now closed.  I
    would like thank everyone who contributed proposals, feedback and patches.
    We received 34 proposals, which resulted in over 340 discussion emails from 23
    people.

    Of the 34 proposals, 18 had some degree of consensus and at least a rough
    draft patch (or git branch) to use to revise the spec.  Two more proposals
    had patches but one was controversial and the other clarifies an existing
    field in lieu of adopting the proposal.

    All of these will now be merged into a single draft 2.0 META spec and
    circulated to the working group for review and refinement.  The working group
    will finalize the new specification by December 1, at which point it will be
    released as final and work will begin to implement the spec in the CPAN
    toolchain and other downstream consumers.

    Again, thank you to all who contributed.  A summary of the results is
    provided below.  All of the proposed patches are also available in branches
    at the github repository: http://github.com/dagolden/cpan-meta-spec

    Sincerely,
    David Golden

    #---------------------#
    SUMMARY OF RESULTS
    #---------------------#

    Some consensus and patch written:

    02. Formally switch to "YAML Tiny" [patch by Ricardo Signes]
    03. Deprecate YAML Tiny dialect for JSON [patch by Ricardo Signes]
    04. Formalize allowed version number formats [patch by David Golden]
    06. Data structures [examples in spec], not YAML [patch by Ricardo Signes]
    07. Enhance granularity of prerequisites [patch by Ricardo Signes and
    David Golden]
    08. Extensibly Group Prereqs [patch by Ricardo Signes]
    09. Clarify intent of 'recommends' and add 'suggests' [patch by David Golden]
    12. Allow Sequences (Arrays) for Prereqs [patch by David Golden]
    15. Add development_requires [patch by David Golden]
    17. Better formalization of license field [patch by David Golden]
    18. Make dynamic_config mandatory [patch by David Golden]
    19. Make repository resource a hash [patch by Ricardo Signes]
    20. Make bugtracker resource a hash [patch by Ricrado Signes]
    21. Formalize optional_features [patch by David Golden]
    22. Clarify author field [patch by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯]
    24. Add a "release_status" field [patch by David Golden]
    27. Long description [patch by David Golden]
    34. Formally reserve keys for private 'in-house' use [patch by David Golden]

    Controversial, but patch written:

    29. Language [patch by Ricardo Signes]

    Not adopted, but patch written to clarify existing, similar field:

    30. Trove-Like Categories

    No consensus or consensus opposes or duplicative or other reasons for
    not including in 2.0:

    01. Update the YAML version declaration
    05. Schema
    10. Add a free-text prerequisite field
    11. OS/arch/platform-specific requirements
    13. Add a post_depends set
    14. Prerequisites should be mutually exclusive
    16. Binary Package Dependencies
    23. Have a "development version" flag
    25. Controlling test suite runs
    26. Specify a DLSIP resource
    28. Short description
    31. Version changes
    32. Steal from other package meta specs
    33. Install Meta files and make them queryable
  • Adam Kennedy at Nov 2, 2009 at 11:24 pm ⇧
    Now is the time, I guess, to add a meta-proposal of sorts.

    I had pondered doing this earlier, but felt it was out of place
    compared to the other elements.

    I'd like to propose that all changes to the META.yml be fully and
    completely defined, without resort to the behaviour of external code.

    That is to say, all cases where a value must be in some enum should
    describe the full list, instead of reaching for "Any value that
    Some::Module allows".

    This is the kind of logic that got us "margins behave like Word 95" in
    the OOXML specification, and it had no place in a formal
    specification.

    Likewise, I'd like to see all additions address BOTH the issue of
    required downstream behaviour from both the CPAN client and the binary
    packagers, and the requirements for back-compatibility.

    That will allow us to actually implement these changes on branches of
    the toolchain modules BEFORE we release the spec changes.

    One of the most common reasons for failure in the specification
    process is implementing wishlist changes to a specification that
    nobody has ever implemented before (witness CORBA et al).

    I'd like to see all these changes working for real before we lock in
    what might be a serious failure (as we've seen with a number of
    existing features in META.yml which were specified before anyone had
    ever implemented them).

    Adam K
    On Tue, Nov 3, 2009 at 9:42 AM, David Golden wrote:
    The public discussion period for CPAN Meta Spec Proposals is now closed.  I
    would like thank everyone who contributed proposals, feedback and patches.
    We received 34 proposals, which resulted in over 340 discussion emails from 23
    people.

    Of the 34 proposals, 18 had some degree of consensus and at least a rough
    draft patch (or git branch) to use to revise the spec.  Two more proposals
    had patches but one was controversial and the other clarifies an existing
    field in lieu of adopting the proposal.

    All of these will now be merged into a single draft 2.0 META spec and
    circulated to the working group for review and refinement.  The working group
    will finalize the new specification by December 1, at which point it will be
    released as final and work will begin to implement the spec in the CPAN
    toolchain and other downstream consumers.

    Again, thank you to all who contributed.  A summary of the results is
    provided below.  All of the proposed patches are also available in branches
    at the github repository: http://github.com/dagolden/cpan-meta-spec

    Sincerely,
    David Golden

    #---------------------#
    SUMMARY OF RESULTS
    #---------------------#

    Some consensus and patch written:

    02. Formally switch to "YAML Tiny" [patch by Ricardo Signes]
    03. Deprecate YAML Tiny dialect for JSON [patch by Ricardo Signes]
    04. Formalize allowed version number formats [patch by David Golden]
    06. Data structures [examples in spec], not YAML [patch by Ricardo Signes]
    07. Enhance granularity of prerequisites [patch by Ricardo Signes and
    David Golden]
    08. Extensibly Group Prereqs [patch by Ricardo Signes]
    09. Clarify intent of 'recommends' and add 'suggests' [patch by David Golden]
    12. Allow Sequences (Arrays) for Prereqs [patch by David Golden]
    15. Add development_requires [patch by David Golden]
    17. Better formalization of license field [patch by David Golden]
    18. Make dynamic_config mandatory [patch by David Golden]
    19. Make repository resource a hash [patch by Ricardo Signes]
    20. Make bugtracker resource a hash [patch by Ricrado Signes]
    21. Formalize optional_features [patch by David Golden]
    22. Clarify author field [patch by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯]
    24. Add a "release_status" field [patch by David Golden]
    27. Long description [patch by David Golden]
    34. Formally reserve keys for private 'in-house' use [patch by David Golden]

    Controversial, but patch written:

    29. Language [patch by Ricardo Signes]

    Not adopted, but patch written to clarify existing, similar field:

    30. Trove-Like Categories

    No consensus or consensus opposes or duplicative or other reasons for
    not including in 2.0:

    01. Update the YAML version declaration
    05. Schema
    10. Add a free-text prerequisite field
    11. OS/arch/platform-specific requirements
    13. Add a post_depends set
    14. Prerequisites should be mutually exclusive
    16. Binary Package Dependencies
    23. Have a "development version" flag
    25. Controlling test suite runs
    26. Specify a DLSIP resource
    28. Short description
    31. Version changes
    32. Steal from other package meta specs
    33. Install Meta files and make them queryable
  • Ricardo Signes at Nov 3, 2009 at 12:45 am ⇧
    * Adam Kennedy [2009-11-02T18:24:26]
    I'd like to propose that all changes to the META.yml be fully and
    completely defined, without resort to the behaviour of external code.

    That is to say, all cases where a value must be in some enum should
    describe the full list, instead of reaching for "Any value that
    Some::Module allows".
    Agreed. Do you know if there are any counterexamples in the current draft?

    I'll try to look a bit later.

    --
    rjbs
  • David Golden at Nov 3, 2009 at 1:36 am ⇧

    On Mon, Nov 2, 2009 at 7:45 PM, Ricardo Signes wrote:
    * Adam Kennedy [2009-11-02T18:24:26]
    I'd like to propose that all changes to the META.yml be fully and
    completely defined, without resort to the behaviour of external code.

    That is to say, all cases where a value must be in some enum should
    describe the full list, instead of reaching for "Any value that
    Some::Module allows".
    Agreed.  Do you know if there are any counterexamples in the current draft?

    I'll try to look a bit later.
    I agree as well. I believe we've removed most if not all.

    The one place that external modules creep back in is version number
    parsing and comparison. I don't think it's productive or perhaps even
    possible to specify anything other than the behavior of
    MM->parse_version and the Module::Build equivalent. Likewise version
    comparison is only sane using version.pm because of how that logic is
    hard-coded into Perl 5.10+. I have, however, tried to give very
    specific, exact examples for usage.

    -- David
  • Adam Kennedy at Nov 3, 2009 at 1:52 am ⇧
    Which version of version.pm, it moves.

    What happens if it changes slightly in the future.

    Adam K
    On Tue, Nov 3, 2009 at 12:35 PM, David Golden wrote:
    On Mon, Nov 2, 2009 at 7:45 PM, Ricardo Signes
    wrote:
    * Adam Kennedy [2009-11-02T18:24:26]
    I'd like to propose that all changes to the META.yml be fully and
    completely defined, without resort to the behaviour of external code.

    That is to say, all cases where a value must be in some enum should
    describe the full list, instead of reaching for "Any value that
    Some::Module allows".
    Agreed.  Do you know if there are any counterexamples in the current draft?

    I'll try to look a bit later.
    I agree as well.  I believe we've removed most if not all.

    The one place that external modules creep back in is version number
    parsing and comparison.  I don't think it's productive or perhaps even
    possible to specify anything other than the behavior of
    MM->parse_version and the Module::Build equivalent.  Likewise version
    comparison is only sane using version.pm because of how that logic is
    hard-coded into Perl 5.10+.  I have, however, tried to give very
    specific, exact examples for usage.

    -- David
  • David Golden at Nov 3, 2009 at 2:07 am ⇧

    On Mon, Nov 2, 2009 at 8:52 PM, Adam Kennedy wrote:
    Which version of version.pm, it moves.

    What happens if it changes slightly in the future.
    Pandora's Box is already open. All we have left is hope.

    On a less mythological note, I'd rather have the one version.pm
    getting it close to right than attempt to write a spec which will
    probably be wrong for some number of edge/corner cases or encourage N
    implementations of the spec which will likely have subtle errors.

    I'm happy to wrap it all in my forthcoming CPAN::Meta module if you
    think that's more useful and want to have a single point of
    abstraction to protect from version.pm changes.

    -- David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedNov 2, '09 at 10:42p
activeNov 3, '09 at 2:07a
posts7
users3
websitecpan.org

3 users in discussion

Adam Kennedy: 3 posts David Golden: 3 posts Ricardo Signes: 1 post

Content

People

Support

Translate

site design / logo © 2021 Grokbase