I have experienced many of the same frustrations with Dist::Zilla as you. Some Dist::Zilla advocates -- including contributors to this thread -- have responded to me just as they did to you in this thread. And I have not been persuaded.
Nonetheless, the tone of your original post is, in my opinion, unhelpful and counterproductive. In the open source world -- indeed, in the online world in general -- people evaluate you not just on the technical content of your posts but on the personal character you project through your posts. And once you post something, it's up there forever. Please bear this in mind when you post here and on other Perl sites in the future.
Thank you very much.
Jim Keenan
make
will build an executable when you are running on some heavy iron and use the -j
option. As a p5p committer I have a shell account on dromedary, a server donated by booking.com++ and maintained by Dennis Kaarsemaker and friends (more ++). On that box I set TEST_JOBS=8, which enables me to configure, build and test perl so fast that I have never bothered to time it (probably less than 5 minutes).
Today, however, was the first time that I learned that running make -j${TEST_JOBS}
can obscure the results of make
.
ext/
to dist/
. I grepped the source code for all instances of ext/Pod-Html
and changed them to dist/Pod-Html
. I then ran a shell function I use all the time to test a branch:
sh ./Configure -des -Dusedevel && make -j${TEST_JOBS} && \
TEST_JOBS=${TEST_JOBS} make -j${TEST_JOBS} test_harness
I noticed something peculiar: The make
part of this command was terminating prematurely, but with no error output at the end where I would have expected it.
Processing BidiBrackets.txt
Finishing processing Unicode properties
Compiling Perl properties
Creating Perl synonyms
Writing tables
Making pod file
Making test script
Updating 'mktables.lst'
I didn't think much of this at first. I typed make
and make
resumed and proceeded to its normal completion, where it instructs you to run make test
. And, after debugging some unrelated issues, everything in make test
PASSed.
But I was puzzled about this and repeated the process one step at a time, only running make
under script
so that I could capture the build output for easier study. I grepped the transcript for Pod-Html and, to my surprise, found one place where there was still a mention of ext/Pod-Html
. This occurred about 90% of the way through `make':
Extracting pod2html (with variable substitutions)
pod2html.PL: cannot find '../ext/Pod-Html/bin/pod2html'
make[1]: *** [pod2html] Error 2
make[1]: Leaving directory '/home/jkeenan/perl/utils'
make: *** [utilities] Error 2
make: *** Waiting for unfinished jobs....
Those "unfinished jobs" ran, but when they completed, make
exited with non-zero status, which meant that make test
did not automatically start. But, because of -j${TEST_JOBS}
, the error output was not to be found at the end of make's output.
When, however, I re-ran make
with no -j
option, make
failed as soon as it tried to build pod2html, so the error output appeared at the end of the transcript:
../miniperl -I../lib pod2html.PL
Extracting pod2html (with variable substitutions)
pod2html.PL: cannot find '../ext/Pod-Html/bin/pod2html'
make[1]: *** [pod2html] Error 2
make[1]: Leaving directory /home/jkeenan/perl/utils'
make: *** [utilities] Error 2
It turned out that pod2html.PL creates the string ../ext/Pod-Html/bin/pod2html
in part by joining the elements of the list qw(ext Pod-Html bin) with OS-appropriate path separators. Once I changed ext
to dist
in this location, make -j${TEST_JOBS}
ran as expected and all tests PASSed.
Moral of the story: If you customarily build an executable with make -j
and make
ends prematurely, you either have to search earlier in the make
log for the error or you have to re-try make
without a -j
value.
Jim Keenan
]]>Special thanks go to Jaron Rubenstein of Rubenstein Tech — they’re hiring! — and the five other Rubenstein staffers who participated in the hackathon.
Like the St Louis Perl Hackathon organized in November of last year, this event was organized around the philosophy of being a distributed hackathon — an event that encouraged the participation of all levels of Perl developers, eschewed elaborate preparations, did not entail a big search for a venue and required minimal out-of-pocket funding. A distributed hackathon is an event which any Perlmongers group anywhere in the world ought to be able to carry off. Any number of participants greater than, say, three counts as a success, particularly if it leads participants to begin making contributions to the Perl ecosphere more consistently.
Where will we hold the next distributed hackathon? Maybe your city! We’ll be happy to help with advice on how to hold one.
]]>mst, I appreciate what you're doing as an attempt to partialize Perl's problems -- even though most of the evidence of those problems which has been presented so far is anecdotal and subjective.
Thank you very much.
Jim Keenan]]>A. In the Perl world, it's a meeting, generally of one day's or a weekend's length, where Perl hackers come together in one physical location (primarily) to work collectively on projects which will improve Perl, CPAN and the Perl ecosystem.
Q. What is a "distributed" hackathon? Is it something like a "distributed" source code control system?
A. In a way. A distributed hackathon, like a distributed source code control system, is designed from the outset to be clonable. In the Perl community, we've had many hackathons over the past eight years, but they generally haven't been planned to be clonable, i.e., easily reproducible in different locations at later points in time. They've been planned as events in one geographic location that when they're over, they're over. They aren't intended to be reproduced elsewhere.
Q. What would it mean for a hackathon to be "clonable"?
A. It would mean that the hackathon was (a) simple enough to organize and (b) conceptually easy enough to grasp that Perlmonger groups in different cities and countries could, with modest effort, throw together events that would share the same thematic focus.
These local hackathons might take place in different cities on the same day, but more likely they would be spread out over a period of several months.
There focus would be on getting local Perl programmers together rather than having people fly in from other cities or countries.
They would be run on a budget as close to $0 as possible. That way, the focus can be on hacking, not on fundraising. The logistics should be simple enough that you can JFDI.
They would be judged a success if they got as few as four local Perl programmers to work collectively for one Saturday afternoon. What one city's Perl hackers didn't finish on a given Saturday could be turned over to the Perl hackers gathering in another city the following week.
Q. So, you're talking about events that are modest in their individual scale, but could add up to something big when spread over time and space?
A. Exactly.
Q. But you said these local hackathons should "share the same thematic focus." What would that be?
Here's one possibility: In the Perl 5 source code there is one document which is Perl's "to do" list. You can view it at http://perl5.git.perl.org/perl.git/blob/HEAD:/Porting/todo.pod. This list holds some items that are very complex, but many others that require only basic Perl knowledge. If Perl hackers in, say, St. Louis worked on a few of those items one week, people in Portland could pick up on them the following week, people in London the next week, people in São Paulo the next, and so forth.
Q. It sounds like you could organize one of these local hackathons without having any big names or subject matter experts present?
A. That's correct. You can generally find subject matter experts online via IRC. They don't have to be in the same room with you. But you *do* want to be in the same room with other local Perl enthusiasts. That's what makes it fun.
For our curious definition of "fun."
Q. Curious indeed! Where do I start?
A. Talk to your local Perlmongers about it and take it from there. Remember, this is meant to be distributed, not centrally organized.
]]>Now, if only we could find out where YAPC::NA::2013 will be held ... :-)
]]>Have you posted or blogged anywhere why you made that transition? I would be very interested in hearing your reasons?
Thank you very much.
]]>In his remarks at the "town meeting" which concluded YAPC::NA::2002 in St. Louis, YAPC founder Kevin Lenzo remarked (paraphrase) that 250 to 400 was the best size for a largely volunteer-driven conference like YAPC. Larger than that? The burden on the conference organizers becomes too great, which leads either to burnout or to need to hire professional conference organizers -- which in turn raises the price point of the conference.
]]>
I think the best way to approach what the Perl Foundation -- or any non-profit organization largely sustained by the efforts of volunteers -- should do is to ask a series of questions:
So my belief is that TPF, like any other volunteer-based non-profit organization, ought to figure out what it can minimally do on a sustainable basis over a multi-year period and do just that. Anything else is icing on the cake.
A few other observations:
Thanks for your thought-provoking post!