On Aug 10, 2010, at 4:23 AM, Michael G Schwern wrote: > I updated Dist::Zilla, that usually fixes things, and I got a face full of > Moose poop. The sort of stack trace that obscures the real problem. Picking > through that, turns out it wants Dist::Zilla::Plugin::ModuleBuild::XSOrPP. > > I install that and try again... another face full of poop. This time its > Dist::Zilla::Plugin::InstallGuide. > > Pooped on again, now it wants Dist::Zilla::Plugin::SurgicalPodWeaver. This > one blows up in tests. I cannot build DateTime. This is a royal PITA.
It sure seems like dzil, if not used properly, can significantly raise the barrier to contribution for a project, even if it does optimize things for the core developers. Just chatted with RJBS about this. He said: > My line has always been that of COURSE it does. It is to optimize the > existing developers' time, not to lower general barrier to becoming a > developer. > > Other people may claim that it doesn't. ... > you can use DZ in ways that do nothing to change the barrier to entry > > i.e., only for release management and VCS integration, or other such > configurations I think that this is especially important for widely-used modules, such as DateTime, that require a build process to test (that is, you can't just run `prove -l t`. So perhaps it'd be helpful to check in the Build.PL, even though it's generated, so that the barrier to contribution isn't so high. Best, David
