Barbie

On Wednesday, Birmingham.pm had their monthly technical meeting. This year we have started a different trend, in that the technical meetings now alternate between technical presentations, and hands-on discussions. While the former is the more traditional talks, slides and projectors, the latter is basically a hacking session. Wednesday night's meeting was a further hacking session, hoping to follow on the success of our April session, which resulted in identifying problems with Test-Database and SQL-Statement.

The meeting was our first at the new venue for technical meetings, the Birmingham Science Park Aston, Faraday Wharf. The site has had a bit of a makeover in the last year, as they are making an effort to encourage new businesses to the area. One of the aims is to invite technology groups to come and hold their meetings there, in their readymade meeting and lecture rooms. A few weeks ago they invited Birmingham.pm to use the facilities, which we accepted. Despite clashing with the England match celebrations, we still ended up having a very productive meeting.

For this hack session we had set our sights on working on a specific aspect of CPAN Testers. At different times, JJ and Johan Vromans have both asked me whether it was possible to determine which version of Mac OSX a particular test report referred to. Unfortunately, due to the nature of how 'perl -V' is constructed, it doesn't truly tell you what the current platform is. This was also made evident in a recent incident, where the report metadata was constructed on two different machines, resulting in conflicting metadata regarding the platform used. The specific problem with referring to the 'perl -V' output, is that it contains the information related to the platform that a particular instance of perl was built with. In some cases this isn't a problem, however as many OSes can be upgraded without necessarily upgrading the version of perl used, this information can be misleading or lacking, when diagnosing fail reports.

Prior to the meeting, I'd posted an outline of I hoped we could achieve on the night. Colin came prepared, having investigated some of the ways other CPAN distributions had approached the problem and provided us with a great starting point. Our first discussion resulted in a consensus that instead of editing the code directly into CPAN-Reporter and CPANPLUS-YACSmoke, we should write an independant distribution that could return the metadata as a hash, with all the relevant details. A set of core keys was required, with anything additional keys being a bonus if available. This would then give us the ability to expand the keys if more metadata was ever needed in the future. We also agreed that we should somehow retain the source of the commands used, in the event that additional parsing is required at a later date, perhaps by consumers who may want more information than we currently use.

We decided on a name for the distribution, Devel-Platform-Info, and agreed a simple plugin framework, which would use the $^O setting to determine which plugin to use. JJ had access to both Leopard and Snow Leopard Mac OSX installations, Colin and Brian worked on Windows 7 and Windows Vista respectively, and I had access to Ubuntu, Debian and CentOS machines. Also joining us was Vik, from the Science Park, who was also running a Mac. Covering the 3 primary testing platform types was a good start, but we knew we would need to look at BSD, Solaris and VMS installations before we'd completely covered the most used platforms.

After a couple of hours of discussion, brainstorming and initial code, we called it a night. We set about a plan to create a Github repo, and join our pieces together, add tests and package ready for a CPAN release. Last night I made a start on these and you can now see the beginnings of our ideas at the devel-platform-info repo on Github. Once the code that JJ, Colin and Brian have worked has been integrated, we'll make a first release to CPAN.

I'm currently looking at VirtualBox to install several OSes that will help us write plugins for other OSes we don't have easily to hand, but we will likely have to see if others can help with less common OSes. It will be interesting to get the initial feedback from CPAN Testers too, as this will identify whether we've really got things right. After that we'll then look at plugging the results into the test reports via CPAN-Reporter, CPANPLUS-YACSmoke and Test-Reporter. This may well be part of a future hacking session :)

Next month will be a technical presentation night, where we'll have Mike Kemp previewing a security talk he will be presenting at several security conferences over the next few months, in America, Canada and Finland. Should be another good night.