Re: sponsor logo on home of CPAN mirror

[Graham Barr]

> On Dec 31, 2017, at 07:25, Henk P. Penning  wrote:
> 
> 
> I don't see how such a change can be kept local ;
> how can it /not/ propagate to downstream mirrors?

If the JSON file was named using the mirror hostname then index.html can 
extract the name from the URL and it wouldn’t matter if the file was propagated 
downstream

Graham

Re: Adjusting CPAN::Mirrors to make it more useful

[Graham Barr]

On Apr 28, 2011, at 11:19 , brian d foy wrote:

 On Tue, Feb 8, 2011 at 4:44 AM, Adam Kennedy a...@ali.as wrote:
 I think I may have implemented what you're looking for several years
 ago for JSAN, which has a client that auto-detected appropriate
 mirrors in a few seconds each time it starts.
 
 http://search.cpan.org/~adamk/Mirror-URI-0.90/lib/Mirror/YAML.pm
 
 I was looking at this, but it seems like the idea of downloading a
 small file from several mirrors isn't a good way to figure out which
 mirrors to use, especially with a large number of mirrors.
 
 I guess you could randomly choose some mirrors and keep checking until
 you find some that are fast enough.
 
 However, shouldn't knowing something about the location can start that
 more quickly when there are several hundred mirrors?

No need for everyone to contact all mirrors.

http://mirrors.cpan.org/ constantly monitors CPAN mirrors for freshness. This 
data can be obtained in JSON form at

http://mirrors.cpan.org/cpan-json.txt

for example

   {
  url : http://ftp.wa.co.za/pub/CPAN/;,
  city : Cape Town,
  region : null,
  country : South Africa,
  continent : Africa,
  cc : za,
  age : 1303986001,
  last_status : ok,
  last_ok_probe : 1304001901
   },

It checks each mirror by fetching a file which is constantly updated on the 
CPAN master site. The age field is the epoch timestamp for that file

Graham.

Re: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN

[Graham Barr]

On Apr 14, 2010, at 6:48 AM, Tim Bunce wrote:
 
 If we separate Perl 5 and Perl 6 distributions within the file system,
 we can distinguish between them easily and without relying on indexes,
 meta data files or other elements of complexity.
 
 True, but is that *really* a significant need? Why bother?

If we do not, then we need a different naming convention for the tar files.
Otherwise how can we upload FooBar-1.45.tar.gz that works for perl5 and also
FooBar-1.45.tar.gz that is written in perl6

The perl5 version may work with perl6, but no visa-versa.

I think there needs to be some separation in the file space in order
to do this. Using a directory perl6/ and controlling that via PAUSE
seems a bit more reliable and consistent than expecting users to use
a particular convention not to confuse files.

 We also thought that it might be relatively easy for to add
 radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
 to place Perl 6 distributions into the proper directory without it
 having to be specified explicitly.  (Whether it *must* be specified as
 one or the other, which would require updates to Perl 5 tools like
 CPAN::Uploader I will defer to Andreas' judgment.)
 
 No need for a radio-box if PAUSE auto-detects from the META file.

I think there are arguments both for and against. For example
what to do if PAUSE cannot detect ?

Graham.

Re: Trimming the CPAN - Automatic Purging

[Graham Barr]

On Mar 25, 2010, at 8:42 AM, Barbie wrote:
 
 Lastly I would also personnally be annoyed if only the latest versions
 were available, as I often make great use of the diff tool on
 search.cpan.org. Having only the latest version renders that great tool
 redundant :(

I use that too :-) and it is very annoying that some authors automatically 
delete
previous releases when they upload a new one.

Graham.

Re: CMSP 02. Formally switch to YAML Tiny

[Graham Barr]

On Oct 9, 2009, at 7:11 AM, 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 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.


+1

Graham.

Re: CMSP 03. Deprecate YAML Tiny dialect for JSON

[Graham Barr]

On Oct 9, 2009, at 7:11 AM, Ricardo Signes wrote:


* David Golden xda...@gmail.com [2009-10-09T07:42:35]

03. Deprecate YAML Tiny dialect for JSON


Strongly agree.


* I would like one violation of the JSON spec: allow Javascript-style
 comments. My one beef with the JSON spec. Elliot


Strongly disagree.  We don't want to have our own dialect.


+1

Graham.

Re: CMSP 04. Formalize allowed version number formats

[Graham Barr]

On Oct 9, 2009, at 7:12 AM, Ricardo Signes wrote:


* David Golden xda...@gmail.com [2009-10-09T07:43:00]

04. Formalize allowed version number formats

Proposal:

Formalize the spec for version numbers as decimal or normalized
dotted-integer (leading v and at least 3 components).  (Dagolden)


Agree.  (Wording should be very clear, with examples, in the spec.)


+1

Graham.

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

[Graham Barr]

On Oct 9, 2009, at 6:46 AM, David Golden wrote:

09. Clarify intent of 'recommends' and add 'suggests'

Proposal:

The 'recommends' flag is not equivalent to Debian recommends.  The  
intent

should be made clear for authors and the toolchain.  If the Debian
definitions are adopted to better match usage by packagers, a  
'suggests'

field should be added as well. (Adam Kennedy)

* C.f.
 [http://www.debian.org/doc/debian-policy/ch-relationships.html#s- 
binarydeps

 Debian definitions]


The debian descriptions seem reasonable.


Comments:

* The current recommends field is ignored, which makes it actually  
work

 like suggests.

* If we redefine the actual meaning to match Debian, recommends  
changes to
 mean install unless you say otherwise. This would result in a  
massive

 install dependency explosion in most cases. (AdamKennedy)


Both are really author recommendations. Neither list is required, so I  
think the
tool chain should default to not installing either. But the tool chain  
could support
a configure option for each so uses could decide to install recommends  
as if they were

a regular dependency.

one option could be though that the failure for a recommended  
dependency to install

could still allow the dependent to install

Graham.

Re: CMSP 13. Add a post_depends set

[Graham Barr]

On Oct 9, 2009, at 6:48 AM, David Golden wrote:


13. Add a post_depends set

Proposal:

Permit specifying of packages that should be installed to provide  
part of a
packages functionality, but should be installed/built *after* the  
package

is installed. (kentnl)


I hate circular dependencies, but they happen.

+1

Graham.

Re: CMSP 15. Add development_requires

[Graham Barr]

On Oct 9, 2009, at 6:49 AM, David Golden wrote:


15. Add development_requires

Proposal:

The development_requires field should specify all prerequisites only  
needed

during development. For example this could include templating or other
preprocessing modules needed to generate the final source. (Slaven  
Rezic)


No strong opinion.

personally I do not store the meta in my repository, so it would only  
be of use

to those who want to use a release distribution as a starting point for
development.

Graham.

Re: CMSP 16. Binary Package Dependencies

[Graham Barr]

On Oct 9, 2009, at 8:12 AM, Ricardo Signes wrote:


* David Golden xda...@gmail.com [2009-10-09T07:49:40]

16. Binary Package Dependencies


No vote, but highly dubious that it could be done in a way we won't  
regret

later.


I agree.

Graham.

Re: CMSP 17. Better formalization of license field

[Graham Barr]

On Oct 9, 2009, at 6:50 AM, David Golden wrote:

17. Better formalization of license field

Proposal:

Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)


+1

From the perspective of search.cpan I would like to see it have two  
properties
1) a name 2) a URL. perhaps for a list of specified names the URL  
could be omitted
but I do not think we should restrict what should be in the license  
field



* When it comes to extensible and unambiguous identifiers, all roads
 eventually lead to URLs... (AdamKennedy);


yes


* Right now, the only dual license you can specify is perl.  What if
 someone wants a dual Artistic 2/GPL 3 license? The current spec  
says this

 can only be a string; why not an array? [[User:elliot|Elliot Shank]]


+1


* Licences can differ per-file - eg, code might be covered by
 Artistic1/GPL2, and doco by something CCish.  Or some code might be
 Artistic1/GPL2 but one file borrowed from another project might be  
GPL2+.
 For plenty of distributions, a single entry (whether it be a string  
or an

 array) is misleading. [[User:DrHyde|David Cantrell]]


maybe some way of indicating that the distribution is of mixed  
licenses and

then listing all the licenses it is a mixture of.

Graham.

Re: CMSP 27. Long description

[Graham Barr]

On Oct 9, 2009, at 8:18 AM, 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 (BST)


Sure, why not?


agreed

Graham.

Re: CMSP 28. Short description

[Graham Barr]

On Oct 9, 2009, at 8:19 AM, 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 similar sites. 'abstract'  
currently
is module-specific (for ex. for Shipwright: Best Practical  
Builder) and
would not tell much about module purpose in general. --Chorny  
01:15, 28

September 2009 (BST)


Opposed.

abstract is not module-specific.  Most things just use the abstract  
of the

main module in a dist.  This is not a needed addition.


agreed

-1

Graham.

Re: CMSP 29. Language

[Graham Barr]

On Oct 9, 2009, at 8:19 AM, Ricardo Signes wrote:


* David Golden xda...@gmail.com [2009-10-09T07:54:51]

29. Language

Proposal:

Perl 6 is coming. Some code in Perl 6 is already being uploaded to  
the
CPAN.  A new language field is an important part of the structure  
we need
to allow Perl 6 to reuse the existing CPAN rather than to try to  
reinvent
the whole thing.  My recommendation would be that this be an  
optional field

with an implicit value of 'perl5' --Jesse


Strongly agreed.


+1

Graham.

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

[Graham Barr]

On Oct 9, 2009, at 8:20 AM, Ricardo Signes wrote:


* David Golden xda...@gmail.com [2009-10-09T07:56:46]

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

Proposal:

For in-house, non-CPAN use, it would be nice to be able to extend  
META.yml
to contain extra keys and data, but any extensions that we choose  
to make

may one day clash with an official key not yet introduced.
[...]

* I thought this was what key names containing a capital letter did?
 CSJewell


Me, too.


Me too


 If not, let's do that instead of X-.


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


Graham.


phew - did I get to the end :)

Re: CMSP 17. Better formalization of license field

[Graham Barr]

On Oct 9, 2009, at 11:53 AM, Ruslan Zakirov wrote:


* There won't need to be a list, apart from perhaps 02packages.   
also,

 cpan:///package/Software::License::Perl_5 works; it makes it easy to
 re-use your own license in a machine-readable way by publishing it  
as a
 package, and is namespaced and indexed; if it can't be found,  
treat as

 Other rjbs 15:21, 28 August 2009 (BST)


[snip]


URL reference to a site is not that good as you can not be sure that
in long term that URL describes license you want. I'm not talking
about special cpan:// URLs, but about regular http://...

Real life example is GPL. http://www.gnu.org/licenses/gpl.html is the
only way to reference the current GPL license at this moment, but when
GPL4 come out that page will be describing GPL4 and you would be able
to find GPL3 on
http://www.gnu.org/licenses/old-licenses/old-licenses.html#GPL.

I'm pretty sure in this as it happened once with GPL2.

So you can not describe GPL3 only with an URL to GNU's site.


Well for sites like search.cpan.org having a link is very useful.

We can only encourage people to use links to pages they know will not  
change.


for a lot of the common licenses we can have a list of standard  
identifiers

which will have links to http://www.opensource.org/licenses

Graham.

Re: CMSP 06. Data structures, not YAML

[Graham Barr]

On Oct 9, 2009, at 9:11 AM, Jarkko Hietaniemi wrote:


I really don't think we should have Perl data structures in files
(that means Perl code, right?), because that indicates doing an eval,
and I don't want to eval any more random code off the 'net than
necessary.


I strongly agree that we should not be having perl code in the META  
file for
security reasons. Although most people would use Safe to read it,  
there would be

those that would not and could get caught out

But the spec should also not be biased to a particular format, IMO. So  
describing
what goes into the META data in terms of perl data types seems  
reasonable.


The spec should contain a separate section which describes how the  
data is serialized


Graham.

Re: CMSP 19. Make repository resource a hash

[Graham Barr]

On Oct 9, 2009, at 3:21 PM, David Golden wrote:

On Fri, Oct 9, 2009 at 7:51 AM, David Golden xda...@gmail.com wrote:

19. Make repository resource a hash
 resources:
repository:
   web: http://github.com/2shortplanks/test-time-hires
   url: git://github.com/2shortplanks/test-time-hires.git
   format: git
   type: github


+1, though I'd drop type.  I don't have strong opinions over whether
format is renamed to vcs or whatever.


yeah I agree. I was too wondering why two fields. I nearly suggested  
dropping

type as-is, but renaming format as type

Graham.

Re: CPAN meeting minutes

[Graham Barr]

On Fri, Jun 29, 2001 at 06:43:13PM -0400, Chris Nandor wrote:
 At 08:36 -0400 2001.06.24, Jon Orwant wrote:
 On Sun, Jun 24, 2001 at 12:28:06AM -0700, Ask Bjoern Hansen wrote:
  On Sat, 23 Jun 2001, Elaine -HFB- Ashton wrote:
   btw - Is there anything we can do at TPC for Paul 'the testing
   maniac' Schinder to acknowledge all of his thankless dedication
   over the past few years in the cpan-testers corner? I
 
  I don't know what, but we should!
 
 I nominated him for a White Camel Award.

Yes, and thank you. I spoke with Brian at TPC and he said they felt his
contribution was too technical for a White Camel award.

 Has anyone heard from Paul in awhile?

Nope

Graham.