Hi Elaine,
Elaine Ashton wrote:
On Mar 28, 2010, at 12:48 PM, Randy Kobes wrote:
Jarkko and I were talking about it this morning - as he's not in
favour of pruning - while trying to think of a way around the size
problem and he reminded me of the idea that, if I recall correctly
was Adreas'
Hi David, hi all,
David Golden wrote:
Except that we're in feature freeze for Perl 5.12, so that won't
actually happen until 5.13. But as soon as Perl 5.12.0 ships, I plan
to pull the trigger on JSON and HTTP::Lite and make them CPAN.pm
dependencies so we can (a) bootstrap CPAN with HTTP and
Hi all,
David Golden wrote:
01. Update the YAML version declaration
Proposal:
The version declaration for YAML has not been --- #YAML:1.0 for a long
time, update it to the current YAML 1.1 equivalent.
I'm opposed on practical grounds, as we want Meta parsing in the Perl
core
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:42:06]
02. Formally switch to YAML Tiny
Proposal:
Change the language referring to YAML to instead refer to YAML Tiny and
update the specification URL to point to the YAML Tiny specification.
(AdamKennedy)
Accept with
Graham Barr wrote:
On Oct 9, 2009, at 6:43 AM, David Golden wrote:
05. Schema
Proposal:
The META spec should come along with a formal schema definition.
(SlavenRezic)
I am not so much concerned about a formal schema. But an official module
to validate, or purge bad data, would be great.
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:44:43]
06. Data structures, not YAML
Proposal:
The META spec should be defined in terms of (Perl) data structures, and not
in terms of YAML. (Slaven Rezic)
Agreed, but the spec should be very clear (perhaps, as said, in an
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:47:00 -0400 2009:
10. Add a free-text prerequisite field
Proposal:
Add free-text entries that *describe* prerequisites that cannot be
described right now, like prerequisite: a working libexpat, Need a perl
with
David Golden wrote:
14. Prerequisites should be mutually exclusive
* I think this would remove a certain amount of useful flexibility,
standard light weight META Object modules could easily automate the
production of the merged list. This feels like sacrificing on a
fundamental point to
David Golden wrote:
16. Binary Package Dependencies
If we could get this right, I'd give all my votes for this. I know that
at least Adam and I had been thinking hard about this kind of thing in a
different context a few years back. It's utterly hard to get right if at
all possible.
David Golden wrote:
19. Make repository resource a hash
+1
Steffen
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:51:29 -0400 2009:
20. Make bugtracker resource a hash
Proposal:
The bugtracker resource shoudl be made into a hash that defines different
types of resources, e.g. web page, email report address, etc. (#toolchain
David Golden wrote:
21. Formalize optional_features
I've had more hassle than luck with optional features, but since some
people make valid use of it, I'd be (slightly) against removal.
+1 to formalization
Steffen
David Golden wrote:
23. Have a development version flag
* Con: Development version'ness would not be determinable post-installation
AdamKennedy
Correction to my earlier reply: If we have the META info available
*easily* post installation (cf. 33), my vote becomes a +1.
Steffen
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:53:28]
25. Controlling test suite runs
Proposal:
The META spec should add flags to indicate that distribution's
tests may be shuffled or run in parallel. (SlavenRezic)
I like the idea in general. I'd just set aside a name
David Golden wrote:
24. Add a release_status field
Obviously supersedes the devel version proposal (23). This would
depend on post installation, easy querying of META information (33).
Steffen
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:53:50 -0400 2009:
26. Specify a DLSIP resource
Proposal:
DLSIP codes should be specified in META.* as a resource.
My impression of DLSIP is that it's nearly as unused as the modules list. Is
this inaccurate?
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:35]
28. Short description
Proposal:
Field for short description that can be used in search (with higher
priority than long description), when generating README, OS packages or
submitting dist to Ohloh, Freshmeat and
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:13]
27. Long description
Proposal:
Field for long description that can be used in search, when generating
README, OS packages or submitting dist to Ohloh, Freshmeat and similar
sites. --Chorny 19:40, 21 September 2009
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:55:36 -0400 2009:
31. Version changes
Proposal:
Description of changes in that versions and tags for changes. Useful for
submission to Freshmeat and for quick review of changes. --Chorny 18:51, 30
September 2009
Graham Barr wrote:
* David Golden xda...@gmail.com [2009-10-09T07:56:46]
34. Formally reserve keys for private 'in-house' use
personally I dislike the case distinction and would rather switch to
using x- prefixes which are used in so many other places to mean private
extensions
+1
Ricardo Signes wrote:
* Steffen Mueller nj88ud...@sneakemail.com [2009-10-09T10:04:44]
As for adopting JSON as the default format: What's the chances of
including a full JSON parser in core?
I believe they are good. JSON.pm has no weird prereqs, works admirably, and
the author has
21 matches
Mail list logo
