Re: Making www.cpan.org TLS-only

On Aug 31, 2017, at 9:10 PM, Ask Bjørn Hansen wrote: > Hi everyone, > > We’re considering how/how-much we can make www.cpan.org TLS-only. > http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html > > I expect that we can’t make the whole site TLS-only without breaking some >

Re: Distribution names are not unique. We need to figure out what to do about it.

On Mar 19, 2013, at 6:14 PM, Michael G. Schwern schw...@pobox.com wrote: I thought you had a typo there, but I see what you mean. Yeah, put that way I agree, package permissions on CPAN should be case sensitive. Existing conflicts grandfathered in as needed. I made distribution and

Re: How to get the Pause ID

On Oct 3, 2010, at 9:28 PM, Ask Bjørn Hansen wrote: Ah, I'm sorry -- I completely missed that the index files were pointing to proper PAUSE files! Anyway, I still think we should deprecate it and recommend people create App::foobar modules with a script runner. I've used it in the past

Re: Leo is skinning www.cpan.org

On Sep 26, 2010, at 7:31 PM, Ask Bjørn Hansen wrote: How we syndicate is (a) easy if we just use the old MIRRORED.BY that old clients support and (b) half-easy if we have a new way to publish information that future clients can support. For new clients I'd really like if we put the

RFC: PGAN

Fellow CPAN-Works: I've posted a [plan] to implement [PGAN], a CPAN for PostgreSQL extensions. I've tried to closely follow the [CPAN philosophy] to come up with a plan that requires a minimum-work implementation that builds on the existing PostgreSQL tools and the examples of the [CPAN] and

Re: RFC: PGAN

On Jan 7, 2010, at 8:38 PM, David Golden wrote: Thoughts in no particular order: Thanks for these, David. * Limiting to gzip/bzip2 tarballs may screw over Windows users who don't have access to a portable extraction program. (CPAN also supports .zip files.) Perl papers over these cracks

Re: RFC: PGAN

On Jan 7, 2010, at 9:06 PM, David Golden wrote: If CPAN required an Makefile.PL/Build.PL, then the clients would know what do with scripts (i.e. install them!). There are raw .pm files on CPAN, too. CPAN.pm generates a Makefile.PL for those. Yeah, crazy, eh? Maybe I will require a Makefile

Re: CMSP 17. Better formalization of license field

On Oct 10, 2009, at 5:21 PM, Jarkko Hietaniemi wrote: gpl The distribution is licensed under the terms of the GNU General Public License (http://www.opensource.org/licenses/gpl-license.php). What version? There are numerous other ambiguous cases. Likewise, (the same as) perl

Re: CMSP 09. Clarify intent of 'recommends' and add 'suggests'

On Oct 9, 2009, at 4:46 AM, David Golden wrote: * 'recommends' or 'suggests' they both imply (to me) they list optional dependencies. Perhaps we could have both, where 'suggests' implies the toolchain should ask whether the user wishes to install listed dependencies, and 'recommends'

Re: CMSP 08. Extensibly Group Prereqs

On Oct 9, 2009, at 6:36 AM, Graham Barr wrote: Rather than have 'config_requires' and 'install_requires' and 'signature_requires' and 'build_recommends', have a two-level system. This requires a small bit of reworking now, but is easy to extend later without adding many top-level keys.

Re: CMSP 07. Enhance granularity of prerequisites

On Oct 9, 2009, at 6:33 AM, Graham Barr wrote: On Oct 9, 2009, at 7:16 AM, Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:45:22] 07. Enhance granularity of prerequisites Agreed. Also suggest (08. Extensibly Group Prereqs) as related and useful. +1 +1 D

Re: CMSP 14. Prerequisites should be mutually exclusive

On Oct 9, 2009, at 6:55 AM, Graham Barr wrote: Modules should only be listed once across all prerequisite categories. E.g. a 'requires' module shouldn't be listed in 'test_requires'; a 'configure_requires' module shouldn't be listed in 'build_requires'. Instead, the spec should define which

Re: CMSP 18. Make dynamic_config mandatory

On Oct 9, 2009, at 4:50 AM, David Golden wrote: * dynamic_config is confusing because if missing, it defaults to 1. Further, the default means that META.yml prerequisites are not definitive and configuration must be run. Making this mandatory will at make this confusing flag more

Re: CMSP 19. Make repository resource a hash

On Oct 9, 2009, at 7:12 AM, Graham Barr wrote: resources: repository: web: http://github.com/2shortplanks/test-time-hires url: git://github.com/2shortplanks/test-time-hires.git format: git type: github +1 +1, though I think I'd use vcs instead of format. Best,

Re: CMSP 21. Formalize optional_features

On Oct 9, 2009, at 7:33 AM, Steffen Mueller wrote: 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 +1 I've stayed away from optional_features because of the hinky extra library that

Re: CMSP 23. Have a development version flag

On Oct 9, 2009, at 7:20 AM, Graham Barr wrote: Packlist 2.0? Agreed. The main use of development status seems to be control if the distribution is indexed as the latest released etc. So having a flag instead of the hackish way we use _ seems a benefit. +1 David

Re: CMSP 31. Version changes

On Oct 9, 2009, at 8:03 AM, Ricardo Signes wrote: * Dieter This seems like getting people to agree on a machine-readable changelog format, which appears only slightly more likely than world peace. Am I misreading it? * Graham Barr gb...@pobox.com [2009-10-09T10:36:48] yeah. I can see the

Re: CMSP 34. Formally reserve keys for private 'in-house' use

On Oct 9, 2009, at 8:06 AM, Ricardo Signes wrote: 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 I agree, but I also don't like the idea of in this zone of the struct, case

Re: CMSP 11. OS/arch/platform-specific requirements

On Oct 9, 2009, at 6:47 AM, Graham Barr wrote: I would like to see a way to specify OS-specific requirements. One option might be to use Devel::CheckOS, which already seems to have a comprehensive list of supported OS names, and have a hash like: It is hard to make such a list

Re: CMSP 17. Better formalization of license field

On Oct 9, 2009, at 1:16 PM, David Golden wrote: In the resources section, there is a license key. Let's make that a hash, instead, with name/URL pairs. Any licenses which may apply to any part of the distribution should be listed. (I.e. multiple entries do *not* mean license options like

Re: CMSP 25. Controlling test suite runs

On Oct 9, 2009, at 1:49 PM, David Golden wrote: -1 I don't think this belongs in META. -1 Agreed. David

Re: CMSP 26. Specify a DLSIP resource

On Oct 9, 2009, at 8:34 AM, Tim Bunce wrote: I think DLSIP codes (which you can blame me for, along with much else besides :) should be deprecated in favor of individual metadata elements. It should be possible to generate a DLSIP-like code from the metadata. +1 to this suggestion. David

Re: CMSP 30. Trove-Like Categories

On Oct 9, 2009, at 2:06 PM, David Golden wrote: * Freshmeat no longer has Trove categories, they were replaced by tags. --Chorny 15:40, 27 September 2009 (BST) -1 for structured categories +1 for freeform author keywords +1 Just what I was going to say. David

Re: CMSP 33. Install Meta files and make them queryable

On Oct 9, 2009, at 8:48 AM, Tim Bunce wrote: Agreed. Not sure about specifics, but in general. Ditto. Triple-o. D

Re: CMSP 02. Formally switch to YAML Tiny

On Oct 9, 2009, at 6:37 AM, David Golden wrote: Accept with modification: YAML Tiny should be as the specification for YAML-like META files, which should be deprecated in favor of META files encoded in JSON. Agreed, assuming JSON is agreed as the spec going forward. +1m though I have no