From The Pragmatic Programmer:

What's the value of pi? If you're wondering how much edging to put around a circular flower bed, then "3" is probably good enough. If you're in school, then maybe "22/7" is a good approximation. If you're in NASA, then maybe 12 decimal places will do.

Alfie John over at rental-property.co.nz wrote to tell that the source code for the entire site, written using Mason and Class::DBI, is available for download.

For someone wanting to see an overview of how either Mason or Class::DBI work with real-world examples, not just samples from documentation, this is a great place to start.

Just announced on the TPF news site, a huge donation to TPF to fund Perl 6 development:

On May 14, 2008, The Perl Foundation received a philanthropic donation of US$200,000 from Ian Hague. Mr. Hague is a co-founder of Firebird Management LLC, a financial fund management company based in New York City. This donation was the result of extensive discussions between Mr. Hague, The Perl Foundation and a Perl community member who wishes to remain anonymous.

The purpose of the donation is to support the development of Perl 6, the next generation of the Perl programming language. Roughly half of the funds will be used to support Perl 6 developers through grants and other means. The balance of the funds will be used by The Perl Foundation to develop its own organizational capabilities. This will allow The Perl Foundation to pursue additional funding opportunities to support Perl 6 development. Mr. Hague wants his contribution to be seed funding in that effort.

The Perl Foundation thanks Mr. Hague in the deepest possible terms. This donation is unprecedented in its generosity, scope and vision, and it is precisely what was needed at this junction in the development of Perl 6. We look forward to the greatest of successes with Perl 6, and this contribution is a key part of making that happen. The Perl Foundation will communicate further developments with the Perl community and Mr. Hague as the pieces of this plan are executed.

Thank you to Mr. Hague for supporting Perl 6's continued development.

Adam Kennedy posted an excellent article about huge performance hits he found with File::Find::Rule. From the docs, there's this sample to find all the *.pm files in @INC:

# Find all the .pm files in @INC
my @files = File::Find::Rule->file
->name( '*.pm' )
->in( @INC );

What this search REALLY says is "Find every single file in all these trees, then do an slow IO stat call to the operating system on every single one to work out which ones are files, and only then do a quick regex match on the file names to keep the 5% that have the ending we want and throw away the 95% that don't".

Now I'm worried about if I'm doing the right order of checking in File::Next, a lightweight file finder that ack relies on.

Take a look at this block of code and see if you can guess what it does.

END: {
print "Exiting...n";
}
print "s = $sn";
BEGIN: {
$s = 'Hello from the BEGIN phase';
}

You'd expect that the BEGIN block sets $s at compile time, so then that gets printed in the print statement, and then the END block executes at the end of the program. Yes, it would, except that those aren't BEGIN & END blocks. They're normal blocks that just happen to be named BEGIN and END.

Credit Randy Lauen for bringing this to my attention. Today at my day job he found a horrifying code construct, one that I'd been using (incorrectly) for quite some time now. You see, these two blocks are not the same:

BEGIN {
# Here's some code that gets executed at compile time
}
BEGIN: {
# This code gets executed at run time, because the colon
# after BEGIN means it's just a plain old label
}

Randy had been tracking down a bug for over an hour and couldn't figure out why his variables weren't getting set at compile time. Turns out the BEGIN block he was modifying was actually a not-special-at-all BEGIN: block. And he found 40+ instances of the spurious colon in the codebase. Of course, INIT, CHECK, UNITCHECK and END are also rendered non-special by a colon as well.

Most of the time, this is invisible. People tend to put their BEGIN blocks at the top of the program, so the difference between a real BEGIN block and a block that happens to be named BEGIN are not noticed. Still, it's a a bug waiting to happen. Sounds like an ideal check for Perl::Critic policy, no? Mike O'Regan jumped to it, and submitted a patch to Perl::Critic, so those of you using Perl::Critic (and if you're not, you should be) can get warned of using colons on those specially-named blocks once a new version is released, shortly I hope.

I'm not the only one to have been doing this. Google Code Search turns up over 100 instances, including some in the core Perl tests (heck, maybe from me!), as well as mailman and POE.

Check your codebases. If you're using ack, it's just:

$ ack --perl '^(BEGIN|END|INIT|CHECK|UNITCHECK):s*{'

Have you fallen prey to this? Let me know.

Perl's big problem is one of perception. The other day, a job candidate asked me "You're moving your web apps from PHP to Perl? Shouldn't it be the other way around?" Why did he think that? The candidate knew no Perl, and only a bit of PHP, so had no technical reason to believe that PHP was better than Perl. So why did he think Perl was subservient to PHP in the web arena?

What I suspect is that Perl is just less visible, and not just in the sense of crap like the TIOBE index where it equates hits for "Foo programming" popularity of the Foo language.  I'm talking about in the real way people see the world of programming.

I'm certain that PHP has become a de facto choice for basic web apps because it's just How You Do It these days. You see enough PHP in the context of the web, it starts to sink in.

Why is Ruby on Rails so popular? Is it better than Perl on Catalyst? Or is it just that people hear about Rails more? I suspect the latter, because perception is reality. When people perceive Perl as being dead, or not as powerful as other tools, it might as well be.

There are three goals I'd like to address:

• Perl needs diversity, needs new blood, both in users and community as well as tools.
• Perl needs more active mindshare in the programming world.
• Perl 5 must continue to be seen as a viable language.

The three actions to take: Decentralize, diversify and colonize.

Perl must decentralize

Perl has a great infrastructure. We have the CPAN. We have the various sites of perl.org. We have Perl Mongers and perlmonks, and so on. Unfortunately, we've grown complacent. It's time to start looking elsewhere for infrastructure and community.

Standardization on tools makes sense if the tools are the best possible tools available. In many cases, the infrastructure already in place in the Perl community may not be the best there is.

Is the Mailman installation running on lists.perl.org the best mailing list solution for you when you need to start a mailing list? If not, then consider other options. Starting a list at groups.google.com is trivial, for example.

Is rt.cpan.org the best bug tracking solution for your modules or projects? If not, then look at other options. Many of my modules, such as ack and WWW::Mechanize are hosted at Google Code, where I use the bug tracking system there.

Is use.perl.org the best place to host your blog? Maybe you should post somewhere else. Certainly that was the case with me. I found that use.perl.org wasn't the news site I wanted it to be, so I started Perlbuzz as an alternative, literally doubling the number of news sites devoted to Perl.

Note that "alternative" does not me "replacement". It's possible to have two similar but diferent projects, websites or whatever that both fill a need. If, say, Perlbuzz replaced use.perl.org, we'd still only have one news site, which is no better a situation than we started with.

Some of the alternatives might not be community-based. Google Code, is not run by altruistic volunteers. Commercial interests will usually have more time and money to spend on providing useful infrastructure. That's no knock on the volunteers, but merely taking advantage of what the commercial interest has to offer.

(I know at some point someone will say "At some point decentralization is harmful." I agree, but we're nowhere near that point. Such a problem to have!)

Perl must diversify

The mantra "There's more than one way to do it" is at the core of Perl the language, but this is not always the case in the Perl community. We must always remember the guiding principle of TMTOWTDI.

The first place to diversify is with people. I suspect, but cannot prove, that the Perl community's size is a net loss as time goes by. We must constantly be trying to bring new people into the fold, to take advantage of their innovations, and to make what we do more fun.

Second, we must be willing to launch new projects, even if they're similar to existing projects. It could be a module, or a website, or an entire application. The knee-jerk resistance to diversity often sounds like this:

• "Why do we need Getopt::Whatever, we already have Getopt::Long"
• "Why do we need another templating system?"
• "Why do we need Jifty/Catalyst/whatever? We already have Maypole."
• "Why do we need Perlbuzz, we already have use.perl.org?"

I've never understood this fear. It sounds like the resistance is based on the premise of "I wouldn't want to do that project, so you shouldn't either." It's the refrain of someone with a closed mind, unable or unwilling to imagine what could be. In the case of similar modules, the refrain usually goes "It's too hard to find the module you want anyway," but that's not a problem of the module, but of the way things are found in CPAN itself. (And if you'd like to address that little bit of decentralization, please take a look at my Rethinking CPAN mailing list.)

Ultimately, fear of the new is counter to the principle of TMTOWTDI. Indeed, plurality is at the very heart of open source, and it's additive, not subtractive. Template Toolkit need not take away from Mason. Perlbuzz need not take away from use.perl.org. Perl didn't take away from awk and shell. In any of these cases, if the new solution does take away from another, then the other solution was an inferior one to begin with.

Decentralizing and diversifying do two things. First, it opens our minds to alternatives that we may not have considered. It makes us more likely to find solutions that are better than what we started with. Second, it helps with colonization, the ultimate goal.

Perl must colonize

The other day, Tim O'Reilly posted on his Twitter feed a link to a cool article about life in the universe which mentioned Von Neumann probes, theoretical space craft that can replicate themselves using materials found in their travels. A single probe could travel some distance, replicate a thousand cloned probes, which would then launch in a thousand different directions, repeating the cycle.

That's what we need to do: Colonize the mindshare of the world to let them know that Perl is still viable, and a hell of a lot of fun. These new Perl lovers will spread the love as well, and the cycle will continue. In terms of action, it means simply "helping make more people aware of Perl as a cool & useful language." Fortunately, it's a case where we can think globally and act locally, even passively.

The biggest effect I see you, the reader, as being able to have is by spreading out Perl's web footprint. I want more places for people to find out about Perl, rather than a few big ones.

This colonization approach goes hand-in-hand with decentralization. Take my ack project, for example. ack has a number of footprints out there:

• A project home page, entirely separate from any perl.org or cpan.org infrastructure.
• A Google Code home page with source repository and bug tracker
• The ready-made search.cpan.org page for ack which points to both.

That's three times places for people to stumble across Perl, to see it mentioned. A separate home page also makes it more likely to get linked from somewhere else, as when Daring Fireball linked to ack and thousands of people came to see about ack. That's thousands of people who went and saw "Huh, here's a tool in Perl."

Of course, a few thousand visitors isn't going to change any mindshare. That's why it's not just me that needs to work on this. Fortunately, decentralizing and diversifying makes colonization easy.

Our Google footprint is pretty bad, anyway. When I search for "perl" in Google, the top five hits are:

• perl.org, which is a good base.
• perl.com, O'Reilly's Perl page, also a good base.
• The wikipedia entry for Perl, which certainly isn't much help for a beginner
• www.cpan.org, with its front page that expects that you know what you want.
• An old perl 4 man page from Carnegie-Mellon University

Is this the best impression that we have to give the world?

Adam Kennedy gets it

Adam Kennedy's Strawberry Perl is a marvel of the principles I've talked about. Strawberry decentralizes, as it uses none of the core perl.org infrastructure, and it diversifies and colonizes by giving Windows users an alternative to ActivePerl, which for many users is not robust enough. When people talk about Strawberry Perl, it helps with mindshare as well.

Adam is a great example of someone who has set out to make improvements to a part of Perl, and implemented it without worrying about permission or duplication, helping Perl as a whole along the way. I thank him for it. I suspect his Perl On a Stick project will have similar results.

How you can help?

The strategy of decentralize/diversify/colonize takes actions at all different levels. You don't have to go create your own Perl distribution, or even write any code. Here are some other ideas to get you started.

• Post a Perl-related web page to Digg, reddit or any of the other social bookmarking websites.
• Bring someone new to a Perl Mongers meeting, even if Perl isn't his/her primary language. Especially if it isn't his/her primary language.
• Go to a user group meeting for another language. See what they're talking about. Share the Perl perspective.
• Start a blog outside of the use.perl.org hierarchy. If you already have a u.p.o journal, keep it, and post to both places.
• Start a mailing list related to a project of yours. Host it somewhere like Google Groups. Don't worry that "people won't be able to find it," because the list of groups at lists.perl.org is no model of organization, either. Besides, the only people who know to look at lists.perl.org are the people that already know there are lists at lists.perl.org. They're not who we're after.
• Start an alternative to perlmonks.org. Perlmonks is a fine site, but it's long in the tooth, daunting to newbies, and frustrating to search. Surely there's a different way to have an online Perl forum that is better in many cases.
• Work on a project that helps cross-pollinate Perl to the rest of the world. The Test Anything Protocol is a good example of this.
• Review a book about Perl. Get it posted to Slashdot or another big tech site.
• Write about Perl in your blog. Even if you think it's not interesting to Perl people, that's fine. Someone will want to read it, and you'll spread that mindshare.
• When you talk about Perl, don't be afraid to use the F-word and the L-word: "fun" and "love".

What do you think?

I'd like to hear your ideas. How can we expand Perl's reach? What have you done to help decentralize, diversify and colonize? How can we keep Perl fun and exciting?

Two comments I don't need to hear: "This will never work" and "This is a waste of time." If that's what you have to contribute, trust that I've taken your insight into account already, and save yourself some typing. Alternative courses of action, however, are more than welcome. Also unnecessary: "None of this would be a problem if not for Perl 6."

Acknowledgements

Thanks to a number of people who have helped discuss these ideas with me as I put them together. These include Pete Krawczyk, Jeffrey Thalhammer, Ricard Signes, Liz Cortell, David Hand, Jesse Vincent and Elliot Shank. I'm sure I've forgotten some, so I apologize if I left you off the list.

The minicpan tool in CPAN::Mini lets you keep a copy of the most recent revisions of each module on the CPAN. Having a mini-CPAN is a great tool for anyone with a laptop, or who wants to look at the CPAN as a whole, or who wants to create a mini-mirror of CPAN to support a large installation without having to hit the net for each module install. An entire mini-CPAN only takes up about a gigabyte of drive space.

Ricardo Signes, CPAN::Mini's author, wrote to tell me:

CPAN::Mini 0.569 includes an obvious optimization: instead of reconnecting to your remote mirror for every file that might need updating, `minicpan` will now keep one HTTP connection open for the entire update. While I can't give numbers that reflect the most common cases of usage, a run that checks every file and finds no updates goes, on my laptop, from about two minutes to about twenty seconds -- about 1/6 the time! It also puts less load on the remote server, making it a friendlier way to keep a local mirror.

Also, Adam Kennedy has just posted about a major upgrade to CPAN::Mini::Extract, a tool to make it easy to get individual files from tarballs, that speeds up extraction:

By shifting expansion to a one-shot extraction to a temp file, and then opening tarballs once from the temp file, I managed to get a two to three times speed up for file extraction. Combined with CPAN::Mini pipelining, this makes CPAN::Mini::Extract massively faster (a 200%-300% overall speed up).

Selena Deckelmann has come back from BarCampPortland with copies of every Post-It on the topic selection board. The topic selection board at an unconference like a BarCamp is where people write on a Post-It a topic they'd like to see presented, and put it on a board for all to see. Whichever topics people vote for are the topics that are presented.

Scanning through the photoset on Flickr is fascinating, as these often are. Topics range from Pirates Paying Artists to WordPress as CMS to How to lie with statistics to Should we replace Congress with a wiki?

Also fascinating to see how widespread Twitter has become, with half the Post-Its leaving @usernames as contact information.

Makes me want to start up a Bar Camp Chicago. And move to Portland.

According to statistics by LaPerla, the freshest 25% of CPAN is newer than how old?

In a new move for TPF, the grans committee is soliciting community input on the proposals for this quarter. Alberto Simões writes...

To this post follows a set of posts with proposals received by the Perl Foundation grants committee during the second call for grant proposals for 2008. Although not usual, the rules of the TPF GC are changing and we hope to make this a rule. Proposals are accepted during one month and after that period, they are posted for public discussion on the Internet. This is important to make GC more aware of the community interest on the project, and to help opening the grants attribution process.

During the month of April we received the following grant proposals:

• Perl 6 Tables
• Solidifying and Extending the Blog Normalize project
• Add Perl support to NetBeans
• Perl on a Stick
• SMOP - Simple Meta Object Programming
• Fixing Bugs in the Archive::Zip Perl Module
• CatalystX::Installer Application
• Perl Survey
  
• Revision Control for all CPAN
• Improve POE::Component::IRC
• DBEditor
• Extending BSDPAN

Please take some time on reading the proposals carefully and give some feedback on the relevance of the proposals.

The article doesn't say where or how to give feedback, or by when. I'd start at the original posting on the TPF blog.

I'd been working on a new functional index for the work website. I created a Pgsql function to normalize the title of a book

CREATE OR REPLACE FUNCTION exacttitle_key( TEXT )
RETURNS text AS $$
DECLARE
key TEXT := upper( $1 );
BEGIN
key = regexp_replace( key,
'^ *(?:A|AN|EL|LA|LO|THE|LOS|LAS)\M *', '' );
key = regexp_replace( key, '[^0-9A-Z ]+', '', 'g' );
key = regexp_replace( key, ' {2,}', ' ', 'g' );
RETURN trim( key );
END
$$ LANGUAGE 'plpgsql'
IMMUTABLE STRICT;

and tested it out, and all looked well. It was marked as IMMUTABLE, so Pg can use it as an index function. I created the index in psql:

create index testbook_exacttitle on testbook
using btree (exacttitle_key(title));

And all was well. Now I wanted to see how long it took to create that index, so from the shell I did:

$ time psql -c'drop index testbook_exacttitle; 
create index testbook_exacttitle  on testbook 
using btree (exacttitle_key(title));'

I knew it would take about 5 minutes to add this index on 6.7 million records in testbook, so I didn't expect it to come back right away. Then I realized that site response fell off the table. ptop showed a couple dozen SELECT queries waiting to run. I killed the process that was running the CREATE INDEX. All the pending queries went on their merry way. Everything was back to normal.

I tried that command line again, and the results were identical. Dozens of queries backed up until I killed the CREATE INDEX process. But why were those queries backing up? That index was not used by any code yet. I asked in #postgresql, but nobody knew the answer. Then, someone said a word that clicked in my head. I made a little change to how I was running the commands, and everything worked just fine.

What was the word that helped Encyclopedia Lester figure out the problem? Turn to page 47 for the answer.

The word was "transaction". If there are multiple commands as part of the -c option to psql, they are executed in in one transaction. DROP INDEX blocks on the entire table, so the entire transaction blocked. When I ran the DROP INDEX separately, and then reran the CREATE INDEX by itself, there was only the long blocking on the new index, which did not yet exist.

(With apologies to Donald J. Sobol and Encyclopedia Brown)

I've created a Twitter feed for Perlbuzz. I'm going to start posting links there on cool things I find throughout the day, but that don't merit a full-blown Perlbuzz or Mechanix story.

Eventually I'll have all Perlbuzz and Mechanix stories posted there automagically, too.

The schedule for YAPC::NA just got published, and there's plenty of good stuff this year. If you haven't decided to make the trip out to Chicago June 16-18 yet, this should help.

Cool stuff that jumps out at me as I peruse the grid: JT Smith talking about the premade application stack that WebGUI uses, Schwern on testing data with The Sims, and Kevin Falcone on timezone handling.

For the beginners, Kent Cowgill's intro to testing is a great way to get introduced to the topic, and I'm sure that Leonard Miller talking about Perl::Tidy and Perl::Critic will help instill good coding practices.

New this year, on Wednesday there will be workshops. Stevan Little will host a 2-hour Moose tutorial, and Jim Keenan will help you get started building and working with Parrot and Rakudo Perl.

Do you have recommendations on must-see talks? Let your fellow Perlbuzz readers know in the comments below.

Linux Magazine has a big introductory article called Looking after your bugs with Request Tracker. RT is the bug tracking system used for Perl 5, Parrot, Perl 6 and all the CPAN modules, at least by default.

Plain Black has announced the WebGUI Users Conference this summer in Madison, WI. WebGUI is a GPLed CMS written in Perl with thousands of customers around the world, and gets 5,000 downloads each day.

We're nowhere near ready to switch to Perl 5.10 at work, even with the release of mod_perl to support it. I'd like to use smart matching all the time. Perltraining.au's put out an article about smart matching in its series of Perl tips that just makes me cry for what I can't use.

mod_perl 2.04 has been released and it supports Perl 5.10. If mod_perl has been a barrier to your uptake of Perl 5.10, there's no longer a reason to wait.

People have been posting in their blogs about what command they run, based on their shell histories. The command that I've seen looks like this:

history|awk '{a[$2]++} END{for(i in a){ 
printf "%5dt%s n",a[i],i}}'|sort -rn|head

That works, of course, but who wants to use awk and the shell? I pulled out the old Data::Hash::Totals module I wrote a while back, along with Perl's built-in awk simulation:

$ history | perl -MData::Hash::Totals -ane'$x{$F[1]}++;' 
-e'END{print as_table(%x, comma => 1)}' | head
207 vim
143 svn
125 make
90 ack
77 cd
45 sdvx
34 ssq
31 ls
25 ./login-fixup
19 tail
alester:~ : cat `which sdvx`
#!/bin/sh
svn diff -x -w $* | view -

and ssq is just an alias for svn status -q.

Sterling Hanenkamp wrote a great response to the now-infamous TIOBE Index article about how Perl is on its way out. This article is the sort of thing I wish I'd done when I was doing PR for The Perl Foundation. Sterling's given me permission to republish it here. Here's a link to the original. -- Andy (Lester)

I've been taking DDJ for a couple years now. It's cheap and occasionally has something interesting in it, but it's been less interesting than I remember it being when I read it in college. I've been much more enamored with the Communciations of the ACM. Today, I received my issue and there's an interview with Paul Jansen of TIOBE Software. In the article, he's quoted saying:

Another language that has had its day is Perl. It was once the standard language for every system administrator and build manager, but now everyone has been waiting on a new major release for more than seven years. That is considered far too long.

Note: This is such a cowardly use of the passive voice. "That is considered far too long"? BY WHO exactly? He's expecting us to swallow his unattributed assertion as if everyone considers seven years "far too long". -- Andy (Lester)

While I am biased, I have to admit that I disagree pretty strongly with Jansen's assessment. First, let me go into the problems with how he came to this conclusion and then explain why I think I'm justified trusting that Perl is in it for the long haul despite my bias that would have me think so anyway.

I want to first evaluate the way Jansen has collected the data he's used to make this statement. TIOBE puts together what they call the TIOBE Index. This is a rating of the popularity of various programming languages. The TIOBE web site claims, "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." How do they measure this? By performing a search for:

+"<language> programming" 

on 5 popular search engines, including: Google, Google Blogs, MSN, Yahoo!, and YouTube. That's it.

What they are measuring is not actual popularity, but the amount of hype surrounding each one. Not only are they measuring hype, but only hype that discusses "programming". What if everyone prefers to say "programming Perl is fun!" That wouldn't get picked up by the search they use. What about "Perl scripting"? Nope. Missed. (Here I should point out that Andy Lester appears to have been on to something when he gave his lightning talk about Perl programs versus scripts at OSCON last year.) In essence, this is, if they're disclosing the complete metric, incomplete. It's a shortcut that might be 90% right or 50% right. This is just poor statistics.

The second aspect of Jansen's comments I take issue with is the statement that there has not been a major release in seven years. That's not strictly true. Perl 5.10 has just been released and it includes new features like the new smart match operator. Beyond that, there has been some very active development on a closely related project, Parrot, and language development toward a huge milestone, Perl 6. Furthermore, where Perl truly shines is in all the development on CPAN. CPAN is getting large and complex enough now that we're having to rethink how it works just so we can find anything on it. This is a good problem to have.

This comment by Jansen does, however, serve to indicate a certain perception gap caused by the long wait for Perl 6. It's even been considered that the name of Perl 6 is harmful to Perl 5. This has been discussed out by others for some time.

In my opinion, Jansen is on shaky ground with his claims and probably only because he's not well informed by anything but his own metrics. I should think that he'd at least research the trends and issues facing the top 10 languages listed by his survey as to provide some better justification for it's accuracy.

As for the reasons I still have warm and fuzzy feelings toward Perl's future, I can list them off rather easily.

1. I am participating in a number of growing projects that depend on Perl's future. Jifty and rethinking-cpan are just a couple I'm involved in. I can point you to several other vital projects that I use or am familiar with.
2. I know of several companies actively pursuing Perl to develop core projects and continuing to train developers. This includes imdb.com, Socialtext, Best Practical, Six Apart, and several others.
3. Recently, Google launched Google App Engine. This tool provides services to Python developers as part of the initial release. The top most voted for issues are first to add support for Ruby and second to add support for Perl, as of this writing.
4. There's an average of 50 new and updated modules being posted to CPAN every day. That's not a small number.

I can probably come up with more, but now it's getting late, so I'd better end this thing. If Perl is going to die, it's got some years left before it happens. I think there will be enough activity to keep it going and increasing during those years rather than dying.

I'd been meaning to write up a summary of blog posts that people had written about the QA hackathon that happened in Oslo a few days ago. Fortunately, Adam Kennedy did it for me, summarizing what the QA thinkers decided, and didn't decide, in those few days in Norway.

[M]y main desire for the Oslo QA Hackathon was to sit a large percentage of the CPAN movers and shakers down in one place and try to iron out some of the inconsistencies around certain metadata issues. I'm happy to report that we managed to obtain either consensus or an agreement to not make a decision and take a "wait and see" approach on a number of issues.

Bonus points for him actually having been there, unlike me. Thanks to all of you for putting your heads together to forge some direction.

David Golden points out there's a much larger writeup of other activities from the hackathon on the Perl QA wiki.