Re: rt.cpan.org is going away

2021-01-21 Thread Olaf Alders via module-authors


> On Jan 21, 2021, at 9:31 AM, Paul LeoNerd Evans  > wrote:
> 
> 
> 
>  rt.cpan.org , the bugtracker used by nearly 80% of all 
> CPAN modules
>  [1], is going to be shut down on 1st March this year [2]; 39 days
>  from when I write this email.
> 
> 
> 
> I am rather concerned about this, as there doesn't appear to be any
> sort of co-ordinated bailout plan or migration of the *huge amount* of
> CPAN modules this is about to affect.

I know this is not exactly what you’re looking for, but there is an attempt at 
generating a static archive: https://github.com/rt-cpan/rt-cpan.github.io 


Olaf



Seeking co-maint on HTML::Form

2018-07-25 Thread Olaf Alders
I’ve tried to contact GISLE via email to request co-maint on March 23, 2018 and 
also via RT: https://rt.cpan.org/Public/Bug/Display.html?id=124382 
 on Feb 9, 2018.  I have 
not gotten any response.

We’ve already moved most of his web-related modules to the libwww-perl Github 
org.  This one feels like a natural fit to move to the org as well, especially 
since WWW::Mechanize makes heavy use of it.

So, I’m asking for co-maint for OALDERS and ETHER on the modules listed at 
https://metacpan.org/permission/distribution/HTML-Form 

HTML::Form
HTML::Form::FileInput
HTML::Form::IgnoreInput
HTML::Form::ImageInput
HTML::Form::Input
HTML::Form::KeygenInput
HTML::Form::ListInput
HTML::Form::SubmitInput
HTML::Form::TextInput

Thanks,

Olaf



Re: Where to report bugs in website 'search.cpan.org' ?

2016-09-10 Thread Olaf Alders

> On Sep 10, 2016, at 7:11 PM, L. A. Walsh <perl-didd...@tlinx.org> wrote:
> 
> Olaf Alders wrote:
>> 
>> This has been in MetaCPAN since early times, so I'm guessing maybe 5 years 
>> that it has been around?  It's a bit late to just back out of the change.  
>> I'd rather get consensus on how to improve it rather than to gut it 
>> entirely, unless there's consensus on just removing it.
>>  
> 
>   Well considering it's, _essentially_, "corrupt" data, any use of it is 
> likely to lead to incorrect results. 
> That doesn't seem like something that should be kept active.  If nothing
> else, it will draw attention from those using to the problems and motivate
> coming up with a fixed/better solution.
> 
> Besides,  It's not like it is a feature in perl; the main request, at this
> point,  was to hide cpan.search.org's use of it until the problems are
> sorted out. 

If you're looking to patch search.cpan.org, that's an entirely different 
matter. I don't know what the process is for patching that site.

Olaf

Re: Where to report bugs in website 'search.cpan.org' ?

2016-09-10 Thread Olaf Alders

> On Sep 10, 2016, at 7:01 AM, L. A. Walsh <perl-didd...@tlinx.org> wrote:
> 
> Olaf Alders wrote:
>> The stakeholders are certainly willing to participate, ... The conversation 
>> was initially derailed, but it has continued in private.
> 
>   This could hardly be expected to be known outside of said discussion.

Indeed.  That's why I raised it here.  :)

>> At least one patch has already been applied to CPANRatings as a result of 
>> the discussion.  It's not unreasonable to assume that more would be welcome.
>>  
> ---
>   Not clear what the patch did,

https://github.com/perlorg/perlweb/pull/187

It makes it easier to get per-distribution info from the CPANRatings API

> but how much effort would it be to remove
> code referencing 'cpanratings' from cpan until some future discussion perfects
> the issues discussed?  I.e. it appears that it might have been premature to
> release a ratings feature, that appears more like Facebook or Google's "Like",
> than a technical review/rating of cpan modules.

This has been in MetaCPAN since early times, so I'm guessing maybe 5 years that 
it has been around?  It's a bit late to just back out of the change.  I'd 
rather get consensus on how to improve it rather than to gut it entirely, 
unless there's consensus on just removing it.


> 
>   If one wants to submit patches, I'm not aware of where the source
> to the cpan 'site' is posted such that one could submit diffs against it.
> Is it a module in CPAN? :-) 

https://github.com/metacpan/metacpan-developer

Pull requests are very much appreciated, but it's generally a good idea to 
discuss patches with us first, so that everybody is on the same page.

Olaf



Re: Where to report bugs in website 'search.cpan.org' ?

2016-09-09 Thread Olaf Alders

> On Sep 9, 2016, at 3:50 AM, L. A. Walsh  wrote:
> 
> Dan Book wrote:
>> 
>> These issues are mostly regarding the cpanratings site itself, which is not 
>> part of search.cpan.org . You can find its issue 
>> tracker here: https://github.com/perlorg/perlweb/issues 
>> 
> 
>   Since search.cpan.org includes the ratings as part of its display of
> results, I find it hard to consider them separate.
>> 
>> And you might also find this discussion interesting, regarding similar links 
>> from metacpan.org : 
>> https://github.com/metacpan/metacpan-web/issues/1653 
>> 
> ---
>   Was interesting for a bit -- but it seems like the discussion
> sorta drizzled out w/o any decisions as it appears the stakeholders are
> not willing to participate.

The stakeholders are certainly willing to participate, but to be honest, there 
are much more pressing issues to be resolved on the MetaCPAN side before we 
start messing with the display or non-display of reviews.  If there's something 
resembling consensus and an accompanying appropriate pull request, we'll be 
happy to deal with it.  The conversation was initially derailed, but it has 
continued in private.  We're well aware of the problem, but it's just low on 
the list.


>  Since the cpanratings people aren't willing
> to even participate in fixing the problems, the ratings should, *at least*
> be removed from the search site -- and hopefully the module-info page,
> as they don't represent useful information about the modules (IMO, as they
> don't say what version the comments were about). 

At least one patch has already been applied to CPANRatings as a result of the 
discussion.  It's not unreasonable to assume that more would be welcome.

Olaf




Re: A question of permissions

2016-05-10 Thread Olaf Alders

> On May 10, 2016, at 4:09 PM, Matt S Trout  wrote:
> 
> On Tue, May 10, 2016 at 12:42:35AM -0700, Buddy Burden wrote:
>>> There is no perhaps involved. Neil knows what he's talking about.
>>> 
>>> Please try to be less condescending to volunteers trying to help you by
>>> telling you your exact mistake.
>> 
>> Ummm ... maybe please try to be less condescending to people you
>> assume are being condescending without any real proof. ;->  All I
>> did was refer to this statement of Neil's:
> 
> I added that paragraph after three other people had independently gone
> "omg" at your response.

I don't want to turn this into a thing, but FWIW, I didn't read Buddy's 
response as being impolite and I'm sure everyone involved in the conversations 
has the best of intentions.

Olaf

Re: Seeking GONZUS for collaboration

2016-01-17 Thread Olaf Alders

> On Jan 17, 2016, at 11:43 AM, Shlomi Fish  wrote:
> 
> Hi Paul,
> 
> On Sun, 17 Jan 2016 11:12:17 -0500
> Paul Bennett  wrote:
> 
>> I'm PWBENNETT and I want to talk with GONZUS about Path::Hilbert::XS and
>> how I can make my Path::Hilbert automatically load your ::XS module under
>> the covers if it's installed.
>> 
>> I welcome advice from anyone else who has experience shimming in ::XS
>> module alternatives if present. I know there are many of you out there; the
>> only one I can think of off the top of my head is INGY, but I don't mean to
>> single him out.
>> 
>> Thanks in advance,
>> 
> 
> I think you can do something like
> 
>   if (eval { require Path::Hilbert::XS; } and (!$@))
>   {
>   # Do something with @ISA or whatever.
>   }
> 
> Or is that not what you mean?

Have you had a look at https://metacpan.org/pod/Module::Implementation ?

Olaf



Re: good form for discontinuing a module

2015-06-09 Thread Olaf Alders

 On Jun 9, 2015, at 8:46 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 
 * John Macdonald john.macdon...@oicr.on.ca [2015-06-08 21:05]:
 We rebuild our environment very night, including downloading all cpan
 modules anew (automatically getting the latest one if it has been
 updated). So, if anyone else has a similar environment and does
 a similar autofetch, then they would be impacted (although in such
 cases, they would probably already have converted to the renamed new
 module).
 
 Note that modules exist on forever on BackPAN. “Deleted” modules are
 only slightly less easy to download than non-deleted ones. The main
 effect of deletion is to de-index the tarball in question, making it
 nearly impossible to find unless you go looking for it specifically.
 
 (Though this is a little less true now with metacpan.org, which lists
 BackPAN releases of a distribution alongside the ones still on PAUSE.
 Only once every release of a distribution is deleted off PAUSE does it
 become unlikely to be found by undirected search.)

I should also add that if you use cpan.metacpan.org as your mirror, then you'll 
be able to download deleted modules as well, since our CPAN is also a BackPAN.  
The module still won't be in the index, but it will be available for download.

Olaf




Re: How to add your avatar to Google search results involving CPAN modules

2013-11-21 Thread Olaf Alders

On 2013-11-21, at 9:06 AM, David Cantrell wrote:

 On Wed, Nov 20, 2013 at 12:29:37PM +0200, Gabor Szabo wrote:
 
 I tried to collect my thoughts and your comments on getting more
 people to use MetaCPAN instead of search.cpan.org.
 
 It is not going to be easy and thus it got a bit long:
 http://szabgab.com/moving-from-sco-to-metacpan.html
 
 I'd be glad to read your opinion on this!
 
 The most important issue to address is why should we prefer metacpan to
 search.cpan. You don't cover this at all.

I'm not here to tell anyone which site to prefer, but a few things that 
MetaCPAN has to offer:

1) Author profile pages
* This can make it much easier to track down an author who is MIA.  If you've 
added your G+, Twitter, etc to your profile, we now have multiple ways of 
trying to contact you about the patch you never applied.

2) ++
* This gives you a simple bookmarking system to track modules you approve of
* This gives other people an idea of what is generally found useful among CPAN 
authors

3) Linking to line numbers in source code. 
* Being able to refer to an exact line of source is quite valuable: 
https://metacpan.org/source/MIYAGAWA/Plack-1.0029/lib/Plack/App/File.pm#L70

4) Easy links to repositories
* When you want to patch something, just look to the left and you'll find the 
repo link, provided the author has added it to the META.* files

5) [Insert feature here]
* It's easy to patch MetaCPAN.  Many fixes and/or features get deployed on the 
same day they're submitted.

MetaCPAN isn't perfect and some people just prefer search.cpan.org.  It's good 
to have choices.  What Gabor is addressing, though, is that since MetaCPAN 
doesn't do well with Google, people are often just presented with *one* option 
(search.cpan.org) when searching for a module.  That's what we'd like to fix.

Olaf
--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter


Re: How to add your avatar to Google search results involving CPAN modules

2013-11-18 Thread Olaf Alders

On 2013-11-18, at 7:27 AM, Todd Rinaldo wrote:

 I commented in the article, but I’ll bring it up here too:
 
 I want to know how we can get google to start showing metacpan results 
 instead of search.cpan.org results. Right now if I search for Module::Build, 
 my first page hit is: http://search.cpan.org/perldoc?Module%3A%3ABuild even 
 duckduckgo does this.
 
 Todd

I don't have a real answer here, but one problem may be the huge amount of 
inbound links search.cpan.org has vs metacpan.org  Having been around so much 
longer, it's natural that search.cpan.org is the clear winner in this 
department.  To a degree, MetaCPAN perpetuates the problem by publishing module 
Pod which, in many cases, links back to search.cpan.org as well.

I know a lot of people are already doing this, but when linking to a module in 
a blog post, on StackOverflow or when linking directly to a CPAN search site in 
your Pod, it would be helpful if the link pointed at MetaCPAN.  Also, you can 
can add links to your MetaCPAN author page on other sites where appropriate.  
That's likely not the only issue that's hurting MetaCPAN in the SEO department, 
but it's one that can be improved over time.  

Olaf
--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter



Re: cpan as generic installer? + Re: module for finding all git repos under a path

2013-09-19 Thread Olaf Alders
On 2013-09-19, at 5:06 AM, Matthew Astley wrote:

 There are other tools for dealing with collections of repositories
  http://joeyh.name/code/mr/
  https://metacpan.org/module/GitMeta
  https://metacpan.org/module/DINOMITE/App-CmdDirs-1.02/bin/cmddirs
  https://metacpan.org/module/Git::Bunch
  https://metacpan.org/module/Git::Megapull  (?)

Apologies if it has already been mentioned, but there is also 
https://metacpan.org/module/App::GitGot

Olaf
--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)



Re: Overwriting RT

2013-02-04 Thread Olaf Alders

On 2013-02-04, at 10:00 PM, Lyle wrote:

 Hi All,
   I just went to submit a bug for DBD::mysql, then noticed the long list of 
 open bugs:
 https://rt.cpan.org/Dist/Display.html?Name=DBD-mysql
 
 Reading the POD showed that the developers use their own bug tracking system 
 and not RT:
 http://search.cpan.org/~capttofu/DBD-mysql-4.022/lib/DBD/mysql.pm#BUG_REPORTING,_ENHANCEMENT/FEATURE_REQUESTS
 
 I'm guessing this may have already come up, so please forgive me if there is 
 already a solution to this and it's something that DBD::mysql needs to 
 implement. But how does one set one's cpan module to not have a link to RT? 
 Ideally, in it's place, have a link to one's own bug tracking system.

Hi Lyle,

Have a look at the resources section of CPAN::Meta::Spec. 
https://metacpan.org/module/CPAN::Meta::Spec#resources  You can refer to the 
META.yml and META.json files from this same dist for concrete examples: 
https://metacpan.org/release/CPAN-Meta

Best,

Olaf
--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)



Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread Olaf Alders

On 2013-01-08, at 1:03 PM, David Nicol wrote:

 
  Recently I checked and only 50% of the CPAN distributions have a link
  to a public version control system:
  http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html
 
 uh, CPAN /is/ a public version control system. You have a favorite VCS and 
 want to make diffs easily? Download, unpack, init, add, commit, work, diff. 

That doesn't sound easy at all.  ;)  For example, if you want to send a simple 
doc patch to an author who has the source code on Github, you can either jump 
through the hoops you're describing or 

a) fork the project on Github
b) edit the file in place on Github
c) click the pull request button

That strikes *me* as much easier and you get built in request tracking.  
Granted, not everyone uses Github, but it's a very minimal workflow.  What 
Gabor is saying is that *if* your dist is actually available via 
Github/Bitbucket etc, you should let people know so that they can help you out. 
 If you do include this in your Meta files, MetaCPAN will add a handy link 
right to your repo, which makes the process even easier.  So, it helps people 
be even lazier about contributing, which is a good thing.  If it doesn't 
scratch everyone's itches, that's OK too. At least, if you include your repo 
url, you're not making me search Github to see if your repo already exists 
there.

 
 On the other hand, a comprehensive CPAN by git as an additional CPAN 
 feature would have a measure of awesome to it, as an alternate distribution 
 and synchronization method.

Well, there is GitPAN, but it needs a lot of love https://github.com/gitpan

Olaf

--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)



Re: The module authors pledge

2011-11-11 Thread Olaf Alders
On 2011-11-11, at 10:52, Todd Rinaldo to...@cpanel.net wrote:

 
 On Nov 11, 2011, at 9:20 AM, John M. Gamble wrote:
 
 I think the barrier to making local forks is already very low and there is 
 no reason to switch the whole thing to Git.
 
 I usually use gitpan when I want to fork a module and can't find it's source 
 history.  https://github.com/gitpan

Gitpan is no longer actively maintained AFAIK. See the issues list for how to 
revive it. 

Olaf

Re: The module authors pledge

2011-11-11 Thread Olaf Alders

On 2011-11-10, at 6:27 PM, Neil Bowers wrote:
 2. Maintainer wants help
 
 The other case is when a maintainer is still around, but either doesn't want 
 to maintain a distribution anymore, or wouldn't mind a wee bit of help.  
 [...]
 
 Maybe the solution to (1) and (2) lies with a site that would be the flip 
 side of prepan.org (orPhAN.org ? :-) ), where modules up for adoption are 
 listed?  But Neil brought the crucial point (I think), that no matter what, 
 the passing of maintainership should never be done totally automatically, 
 but should always at least get the blessing of the gardians of 
 modu...@perl.org or the ex-maintainer herself. Just, y'know, as human sanity 
 check.
 
 There could be two ways you could tag a module:
 
   (a) up for adoption
   (b) open to adoption requests

(c) open to co-parenting?

Olaf
--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)



Re: The module authors pledge

2011-11-10 Thread Olaf Alders

On 2011-11-10, at 5:36 AM, Neil Bowers wrote:

 Shmuel wrote:
 I am against the 'if I die' part. As we are all communication over the net, 
 it is very difficult to know why a person have stopped responding. 
 And it make the statement a bit scary.
 
 And Raphael wrote:
 The real problem with 'if I die' is that there is no way of knowing: the
 only indication one gets is that mail is not being answered, this clause
 is therefore pointless.
 
 Having had to deal with this issue for a friend, I'm going to try and put in 
 place mechanisms
 so that when my time comes, notifications for stuff like this will happen.

It's not something I had even considered until I happened to take over 
maintenance of a module whose original author had passed away.  So, I can see 
how it is useful and I would have no issues with including this in my pledge.

Olaf
--
Olaf Alders
o...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)