I've just updated the wiki with the achievements around the projects I
was associated with. I'll paste them below.
http://2013.qa-hackathon.org/qa2013/wiki?node=Achievements
In addition I fleshed out the Lancaster Consensus conclusions according
to my photographs of the white board and my own rec
TL;DR version...
IMO we only need to clarify what "conflicts" means and what actions CPAN
tools should take.
We talked in the Consensus Dome about the need for and meaning of the
"conflicts" relationship in the CPAN::Meta::Spec.
https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec
IIRC the co
On 04/15/2013 12:20 PM, Michael G. Schwern wrote:
> I've just updated the wiki with the achievements around the projects I
> was associated with. I'll paste them below.
> http://2013.qa-hackathon.org/qa2013/wiki?node=Achievements
Thanks to all the Hackathon contributors for these updates! As a CP
On 13-04-15 01:56 PM, Michael G. Schwern wrote:
Why we need this, why you can't do it with "requires" is because this is
for modules which you do not depend on. Often they depend on you.
MooseX::Blah depends on Moose, so Moose declares conflict with versions
of MooseX::Blah it breaks.
This req
On Mon, Apr 15, 2013 at 11:02 AM, Mike Doherty wrote:
> On 13-04-15 01:56 PM, Michael G. Schwern wrote:
>>
>> Why we need this, why you can't do it with "requires" is because this is
>> for modules which you do not depend on. Often they depend on you.
>> MooseX::Blah depends on Moose, so Moose de
On 4/15/13 7:02 PM, Mike Doherty wrote:
> This requires Moose maintainers to know about all the things their
> releases break. Have you considered reversing the directionality so
> MooseX::Blah knows about the things which break it? That seems like a
> more likely scenario to me, and lets the right
