Use links to metacpan.org in documentation, spec and META.json

[karenetheridge]

No description provided.

[dagolden]

Unless there is a really good reason why this needs to be changed, I'm not very inclined to apply it.

Yes, metacpan.org is the new trendy, but search.cpan.org is still .cpan.org and thus a more "official" place to link to.

Even ignoring that, picking one over the other is entirely arbitrary, so given that one arbitrary decision was made, I see little reason to flap to another.

[karenetheridge]

It's about driving more search traffic to metacpan in preference to s.c.o, mostly.

[ranguard]

Side note: most of *.perl.org now points to metacpan (ldap.perl.org and dbi.perl.org switched in the last couple of weeks)

[wchristian]

@xdg: While many people who ask to make metacpan the default probably don't realize this consciously, because they never stop to think about it, the reason for doing so is simply that metacpan does have a point where bug reports, feature requests and patches can be sent such that they will end up public, discussable and improvable through discourse.

That said metacpan does have its drawbacks and issues and as of yet and for the forseeable future i regard both as necessary and fall back to sco once every two weeks or so.

So, this rambling means for me that while the answer is not obvious, the question seems worth asking and should be treated seriously.

[oalders]

MetaCPAN does have its flaws and I too find myself at s.c.o. every so often trying to sort something out. ;) Having said that, for most use cases, I feel like MetaCPAN has a better user experience. The author profiles make it easier to track down active authors, being able to link to lines of source code is a big win and the ++ system does give some good feedback on which modules are currently in favour. And, as @wchristian has pointed out, I (or anybody else) can improve MetaCPAN. I see no obvious way to improve s.c.o.

I see s.c.o. as necessary even if/when MetaCPAN gets all the issues ironed out, because just having one of something doesn't seem like a good idea to me. Having said that, if someone is new to Perl and is just forming an impression of the Perl world, MetaCPAN would be the entry point I'd prefer to send them to.

There's also the SEO standpoint where we're gaining traffic steadily, but we don't have the sheer number of inbound links which s.c.o. has. As more links get added back to MetaCPAN, the playing field slowly gets levelled.

[dagolden]

Hey, I love metacpan.org. But going around trying to s/sco/metacpan/ strikes me as dangerously close to a political/religious crusade, which I instinctively resist.

The 'url' field of meta-spec is essentially meaningless. I've pushed some of this to master, but in a more balanced way.

[andk]

David Golden notifications@github.com writes:

Hey, I love metacpan.org. But going around trying to s/sco/metacpan/ strikes me
as dangerously close to a political/religious crusade, which I instinctively
resist.

Thank you, David, highly, highly appreciated.

andreas
(who also loves metacpan)

[karenetheridge]

Since this was rolled back, I'm reopening this as a breadcrumb for fixing the issues that it caused, and then reapplying the patch or something similar when all is safe and can be guaranteed to stay safe.

context:

05:27 < hoelzro> hi toolchain devs
05:28 < hoelzro> I'm getting testing failures for Module::Build on 5.12.x and previous
05:28 < hoelzro> here's the build output: https://gist.github.com/hoelzro/9367136
05:28 <+dipsy> [ build.log ] 
05:28 < hoelzro> I looked to see if this issue had already been reported, and I couldn't find it
05:28 < hoelzro> but I can't imagine I'm the only one who's seen this
05:28 < hoelzro> but maybe my env is messed up
05:47 <@Mithaldu> looks like module build wasn't updated to handle a recent change in CPAN::Meta to update the urls
05:48 <@haarg> looks like the new CPAN::Meta broke it
05:48 < hoelzro> that's what I was thinking
05:55 < rwstauner> dmarr: i have this alias on my pc, but admittedly it's been a while since i used it: ctags -f tags --recurse --totals --languages=Perl --langmap=Perl:+.t lib t/lib
05:59 <@xdg> hoelzro, haarg, I'll unbreak it via CPAN::Meta.  The change wasn't that important and I don't want to inflict upgrade cycles on people if we can avoid it.
05:59 < hoelzro> xdg++ # unbreaking
06:00 <@haarg> although Module::Build should probably be fixed to not test that specific url
06:00 <@xdg> hoelzro, could you *also* open an issue for it in the Module::Build repo -- it ought to get fixed anyway or at least be noted
06:01 <@xdg> M::B needs "fixing" for a lot of hard coded crap.  (sigh)
06:01 < hoelzro> xdg: of course
06:05 <@BinGOs> according to http://perl5.git.perl.org/perl.git/commitdiff/b686b33c it broke EUMM as well.
06:05 <+dipsy> [ perl5.git.perl.org Git - perl.git/commitdiff ] 
06:07 <@leont> M::B's test suite has a lot of fragile stuff in it
06:07 < hoelzro> ticket created
06:09 <@xdg> CPAN::Meta shipped.  Let's hope that unbreaks things.
06:09 <@xdg> leont, s/'s test suite//  :-)
06:10 <@leont> Hehe
06:10 <@leont> That is sadly very true :-/
06:10 <@xdg> hoelzro, if you're feeling heroic, you could write a test for CPAN::Meta that exercises EU::MM and M::B to help catch anything like that in the future
06:11  * GumbyNET7 CPAN Upload: CPAN-Meta-2.140640 by DAGOLDEN http://metacpan.org/release/DAGOLDEN/CPAN-Meta-2.140640
06:12 < hoelzro> we'll see how my schedule feels about heroism =)
06:14 <@haarg> xdg: that would be good as a dzil plugin actually
06:15 <@haarg> a dependents test on release, with a list of modules to check
06:15 <@xdg> haarg, good idea. Well volunteered?  :-)
06:16 <@xdg> or enlist ether -- sounds like her kind of thing
06:17 <@leont> Yes, that does sound like a very good idea
06:17 <@haarg> should be pretty simple.  could just use Test::DependentModules
06:17 <@leont> Didn't Tux recently post something about dependents testing?
06:18 <@Tux_> yes, on PM
06:19 <@Tux_> http://www.perlmonks.org/?node_id=1076783
06:19 <+dipsy> [ Will I break CPAN? ] 

[ribasushi]

@karenetheridge From the log you pasted:

05:59 <@xdg> hoelzro, haarg, I'll unbreak it via CPAN::Meta. The change wasn't that important and I don't want to inflict upgrade cycles on people if we can avoid it.

To clarify the "when all is safe" part: I read @dagolden's line above as "there is no point pushing this change until way later down the line when an unavoidable technical need of a dual-life upgrade arises and the fix is sucked in as part of that"

[dagolden]

I'm closing this PR as I'd rather have the reminder as an issue not a PR, since stalled PR's just clutter up the list of things that actually need review.

[mohawk2]

perl-pod/pod-simple#61

Edited to point at right location for this issue.