Re: Preserving git history across repositories

On Sun, Dec 22, 2013 at 09:51:23AM -0500, James E Keenan wrote: Is it possible to preserve the commit history of a tree of files as it moves out of one repository and into another? This is a bit fiddly but it's quite doable. The steps look something like this: - create your new repository,

Re: File::ShareDir - Outstanding modernization

I am not opposed in principle to redesigning File::ShareDir, but I want to be *very* clear about the proposed design changes, impact on various parts of the toolchain, and back-compatibility concerns before anything moves beyond the design phase. This code sits at the very heart of the cpan,

Re: CPAN River - water quality metric

> I think “has a META.yml or META.json” is worth keeping in I'm surprised this one is being discussed at all. IMO, not having a META file should disqualify the distribution from being considered at all. At Berlin last year we talked about making it mandatory, and held off "for now" so the

Re: Possible bug in Test::Builder, fix is easy, but might break things

> The problem is that parent_todo is not considered when setting the OK's in the details in subtests. That means if a subtest ok fails, and the parent is in todo, the 'ok' and 'actual_ok' are both set to false. Why is this a bug? After all, it's only the top level of TAP that ever matters when it

Re: Should Test2 maintain $! and $@?

> Test2, the dist, is just internals. It provides no tools. It does not have ok(), is(), etc. Um, so... what *is* Test2 then? (And the second question would be: and what does it have to do with Test::More?) Without context, your first question is equivalent to "should Foo::Bar maintain $! and

Unresponsive cpan mirror: cpan-sj.viaverio.com

Hi toolchainers, I'm not sure who maintains the list of cpan mirrors, but cpan-sj.viaverio.com is now unresponsive, and should be removed from the list that CPAN.pm uses (and any other cpan clients). - Karen Etheridge (et...@cpan.org)

Re: Renaming the "QA Hackathon"?

When I saw this thread title I thought it was going to be discussing the "QA" part of it, and I thought "yeah, right on!".. I totally agree with Neil's points about what we do not being a "hackathon" though. ..And I also like the idea of changing the QA bit to Infrastructure. Perl Infrastructure

Re: Thoughts on Kik and NPM and implications for CPAN

Done: https://github.com/andk/pause/issues/204 On Wed, Mar 23, 2016 at 10:57 AM, David Golden <x...@xdg.me> wrote: > On Wed, Mar 23, 2016 at 1:39 PM, Karen Etheridge <p...@froods.org> wrote: > >> I would suggest an email alert go out to the modules@ list (or another &g

Re: Thoughts on Kik and NPM and implications for CPAN

Should an author be able to delete a currently-indexed distribution on the CPAN? Yes, without reservation or exception. Open source is free, and that freedom includes removing my consent for my name to be attached to a publication at any time. However, we (the CPAN community) can do a lot of

Re: Passing some torches

I believe Leon Timmermans is already established as a maintainer of Module::Build, so things should be fine there. Since I'm already a release wrangler on YAML-Tiny, upon which CPAN-Meta-YAML is based, I'm happy to coordinate its releases as well. I'm happy to take on Perl-OSType too since it is

Re: YAML (maybe other modules) might need CPAN smoking

There should be -TRIAL releases of anything this far upriver, at the very least. On Tue, Jul 5, 2016 at 5:34 AM, Sawyer X wrote: > YAML.pm. > > It isn't tool chain, but it is relatively upriver, so I thought this > group would be interested. Additionally this idea can extend

Re: No . in @INC breaks CPAN

> In this case, adding '.' to the distribution's Makefile.PL made no difference. I had to add "use lib ('.');" to Auxiliary.pm to enable it to locate 'eligible_chars', after which 'make test' PASSed. > Based on this example and several other failures, my hunch is that many of the failures which

Re: Move dev release tarballs to GitHub?

On Sun, Apr 10, 2022 at 6:43 AM Ricardo Signes < perl.cpanw...@rjbs.manxome.org> wrote: > Looking good. "plenv install" finds the file at metacpan, which, it > appears, is actually a backpan mirror. This suggests that we can safely > delete these old dev versions. > Running: perlbrew install

Re: Increasing podlators Perl dependency to 5.12

On Sat, Mar 16, 2024 at 6:22 PM Russ Allbery wrote: > I wanted to provide some advance notice that I plan to increase the > minimum Perl dependency for podlators (Pod::Man and Pod::Text) to 5.12 > from 5.10 in the next release. > Sounds good to me; I appreciate the heads up! It's worth noting