A few weeks ago I attended a Perl 5 day organised by the Perl Foundation and I promised to summarise the day. It's hard to summarise a day-long meeting with no agenda. We were around 25 people; split about half way core Perl developers and large enterprises which use Perl. Choice fact: the BBC serves around 2k requests per second with mod_perl. An enterprise is multiple people working together with people coming and going so standard interfaces are required: looks like Damian's Perl Best Practices will help here.
Packaging seems to be a major problem for large companies. Many ideas were thrown around based upon "blessed stable CPAN modules" (like Activestate Perl) but enterprises need certain specific things, not old stable modules. The struggle between needing the stable and needing the newest version of a module or perl came up a few times. There is no good way to solve this, although creating flexible packaging tools might help. Of course, once you start packaging CPAN modules, you also start caring about the C libraries and external programs they depend on...
For perl 5.10 one of the original plans was to throw all the modules out of the core (keeping the bare minimum needed to install modules) and moving the modules into a seperate SDK. This helps the core size be small and portable and makes it easier to upgrade modules in the SDK (but more maintenance work and testing for the SDK). This idea was brought up again. Also that we need more volunteers to handle perl bug triaging.
Volunteers are always a short supply, but it did seem odd that there were some companies there which are making millions, if not billions, of pounds a year with Perl and yet they turn up to the Perl Day to complain about something that they could easily have hired a core Perl person or pumpkin to do. The Perl Foundation isn't Perl, Perl is what you make it ;-)
Overall lots of talk and not many action points, which is a shame as I'm an action kinda person.This post was brought to you with the cry of the yellowhammer bird...
Here in Seattle I'm pimping Damian's book. When one writes Perl as a profession, they should stick to the guidelines. There's still room for Perl-as-art, but we have a common foundation that's not difficult to agree on. The packaging and distribution are problems. But this is the right community to solve those problems.
written that 10 years ago or 2 days ago for all that has changed since then. Ah, the joys of enthusiasm for an SDK that gets shot down nearly every time it comes up.
And CPAN wouldn't be such a collossal pain in the ass if more/better/complete metadata would be included with each distribution, but I suppose that, too, has fallen by the wayside.
Why would/should people give money to an organization that seems to be unable to fund the very problems that have needed fixing for 10 years or more and instead spend it on air travel for 'celebrities' to conferences and obscure projects that no one ever hears about?
Re:you could have
nicholas on 2005-10-16T22:19:55
Why would/should people give money to an organization that seems to be unable to fund the very problems that have needed fixing for 10 years or more and instead spend it on air travel for 'celebrities' to conferences and obscure projects that no one ever hears about?I think because TPF doesn't have a specific core engineering remit, and hasn't thought it needed to, for a couple of reasons. Firstly because for most of Perl 5's life Perl 5 development has done just fine thanks to patronage offered by various employers allowing their employees to devote considerable time to core Perl work, and secondly because they'd not realised that the killer strength of Perl was not the core distribution, but CPAN, and that CPAN needed more active management.
But change is needed, because those days of patronage are gone now, and indeed have been gone for a couple of years, and no-one seems to have noticed quite yet. Plus Perl is now generally now not sufficiently broken that anyone really feels a pracital business need to fix any part of it to get their job done. Jarkko did a fantastic job making 5.8.0 work sweetly, which has this knock on effect that the lack of even medium hanging fruit makes it hard for anyone to break into core development by fixing bugs that scratch their itches, because there are fewer serious itches now.
As to CPAN, I don't think that anyone has felt the need to try to tame it, because none or nearly none of the volunteers contributing code to CPAN actually face the sorts of problems that the enterprise users face, and the enterprise users are sadly mostly silent and faceless in the perl community. I think that barbie sums up part of the problem in his journal entry about CPAN testers no longer testing with 5.6.x, but this is only part. I don't have a solution, and I'm not convinced that a solution is easy to find, given that CPAN works as a decentralised system, without someone in central control. I can't see that "finding" a solution and then attempting to "impose" it will work.
