August 2011 Archives

As announced by Karen Pauley at this year's YAPC::EU in Riga, Latvia, NET-A-PORTER.COM, the world's premier online luxury fashion retailer, will donate $10,000 to the Perl 5 Core Maintenance Fund. NET-A-PORTER is committed to innovations in web technology and has created a bespoke e-Commerce platform to offer its customers a fast, responsive and interactive user experience. It uses Perl for a number of its programs and makes this donation as a sign of its commitment to the language and an acknowledgement of the work that the Foundation is doing.

Richard Lloyd-Williams, Head of Group IT at NET-A-PORTER, explains, "It is fantastic to be giving something back to the Perl community. Without the work of the Perl Foundation we would not be able to customise and build on the NET-A-PORTER platform as effectively as we have done. This donation is one way we've chosen to show our gratitude."

"The generous support from Net-A-Porter will allow us to extend and expand grants to Perl developers who are working on the essential maintenance of the Perl 5 Core," said TPF president Karen Pauley, while attending YAPC Europe. "This will directly benefit the many thousands of Perl users around the world, helping us improve the language experience for everyone."

NET-A-PORTER.COM was launched in June 2000 and has since successfully established itself as the world's premier luxury online fashion retailer.  Presented in the style of a fashion magazine, NET-A-PORTER features collections from over 350 of the world's most coveted designers including Chloé, Marc Jacobs, Burberry, Miu Miu, Stella McCartney and many more.  With its acclaimed editorial format, express worldwide shipping to 170 countries (including same day delivery to London and Manhattan), luxurious packaging and easy returns, NET-A-PORTER offers an unparalleled shopping experience.

It has been recently announced that LOVEFiLM, Europe's largest subscription service, are supporting the Perl community by assisting with the maintenance of regular programs such as memberships and grants. The people at LOVEFiLM have seen a rapid expansion of both their service and product over the past seven years and they are all proud of its system built upon Perl.

Mike Blakemore, Chief Technology Officer at LOVEFiLM states: "Perl underpins all the technology at LOVEFiLM - from warehouse, customer service, website, and back end processes. Its flexibility lets us innovate quickly and its maturity means there are developers rich in experience when it comes to operating in Perl."

Karen Pauley, Perl Foundation President stated: "The support from LOVEFiLM is an essential component of the relationship that the Perl community shares with the commercial world. I am happy once again to see another successful Perl company proud of its involvement in the Perl Foundation and the community we support."

LOVEFiLM's multi-platform service is revolutionising the way in which its 1.7 million members can watch and enjoy films - by streaming content via PC, internet-connected devices and PS3™ and sending DVDs by post.

LOVEFiLM currently operates in the UK, Germany, Sweden, Denmark, and Norway employing 380 staff - with a view to boosting its London-based workforce by 20 per cent in the next few months in-line with the company's digital expansion.

The Perl Foundation is proud that such a highly visible company is proud to show its commitment to the Perl language and especially to the community built around our language.

Dave Mitchell writes:

As per my grant conditions, here is a report for the July period.

Spent it mainly working on fixing the design flaws in re_evals (i.e. /(?{...})/ ).

Over the last month I have averaged 6 hours per week.

As of 2011/07/31: since the beginning of the grant:

73.0 weeks
799.0 total hours
10.9 average hours per week

There are 101 hours left on the grant.

Report for period 2011/07/01 to 2011/07/31 inclusive

Summary

Effort (HH::MM):

0:00 diagnosing bugs
26:10 fixing bugs
0:00 reviewing other people's bug fixes
0:00 reviewing ticket histories
0:00 review the ticket queue (triage)
-----
26:10 Total

Numbers of tickets closed:

0 tickets closed that have been worked on
0 tickets closed related to bugs that have been fixed
0 tickets closed that were reviewed but not worked on (triage)
-----
0 Total

Short Detail

22:10 [perl #34161] METABUG - (?{...}) and (??{...}) regexp issues
4:00 [perl #58530] Bus error with constant + overload + stash manipulation + bless ]

Nicholas Clark has submitted a grant proposal under our new Perl 5 Core Maintenance Fund.

Before we vote on this proposal we would like to get feedback and endorsements from the Perl community. Please leave feedback in the comments or send email with your comments to karen at perlfoundation.org.

Name: Dr. Nicholas Clark

Contact Information:

IRC: nicholas
Email: [email protected]

Project Title: Improving Perl 5

Synopsis:

Free up one of the Perl 5 core's key contributors to work non-stop on making Perl 5 better.

Benefits to Perl 5 Core Maintenance:

Perl 5 is an amazingly flexible language, and in the 16 years since Larry Wall released 5.000, the Perl interpreter has been modified in ways no-one could have foreseen, and ported to platforms that didn't even exist then. Not unsurprisingly, the Perl interpreter's 16 year old codebase has suffered in the process, and is not as clean or tidy as it could be. This makes it harder for people to learn how the internals work, getting in the way of bringing new blood into the project. For people experienced in the internals, this makes it harder to find and fix bugs, and to add desired new functionality. Funding work to reduce the technical debt of the internals will increase the efficiency of the existing maintainers, and make it easier to recruit and train new maintainers in the future.

Deliverable Elements:

I propose to adopt the same model as Dave's successful ongoing grant.

Like his grant, there are intentionally no pre-defined deliverables for this project. I intend to devote around 400 hours over the next 3 months to work on improving the core, paid by the hour at the same below-commercial rate as Dave. Like him, I would post a weekly summary on the p5p mailing list detailing activity for the week, allowing the grant managers and active core developers to verify that the claimed hours tally with actual activity, and thus allow early flagging of any concerns. Likewise, missing two weekly reports in a row without prior notice would be grounds for one of my grant managers to terminate this grant.

Exactly as Dave does, once per calendar month I would claim an amount equal to $50 x hours worked. I would issue a report similar to the weekly ones, but summarising the whole month. The report would need to be signed off by one of the grant managers before I get paid. Note that this means I am paid entirely in arrears.

At the time of my final claim, I would also produce a report summarising the activity across the whole project period.

Also, (the "nuclear option"), the grant managers would be allowed, at any time, to inform the board that in their opinion the project is failing, and that the TPF board may then, after allowing me to present my side of things, to decide whether to terminate the project at that point (i.e. to not pay me for any hours worked after I was first informed that a manager had "raised the alarm").

I view this grant as a proof of concept - if it goes well for everyone involved, I expect to apply to extend it. Hence the specific tasks mentioned below are given as examples of the things I'd like to get done over a longer period, not a list things I expect to get done in three months.

Project Details:

I think that the work that I would do to improve Perl 5 would mostly fall into one of 4 main classes: refactoring, bug fixing, helping other contributors, and adding features - with refactoring the most prominent and adding features the least. "No plan survives contact with the enemy" is often the case when it comes to working with the Perl 5 core - the proper fix for a problem usually turns out to involve a lot of collateral bug fixing or other improvements. Hence I can't give a meaningful list of "what I will work on" because it will rapidly become so outdated as to be completely wrong. Instead, I have an illustrative list of example tasks, and metrics to judge success:

1: Refactor the existing implementation (both build time and run time), without adding or removing features.

For all of these, suitable metrics to judge success are reducing any of:

a: amount of code (without increasing code complexity - golfing is cheating)
b: size of compiled code (executables and shared objects)
c: run time memory use
d: run time CPU use

For example I currently have ideas to investigate on how to:

a: further reduce the size of various structures such as symbol tables
b: remove duplication between headers, dump.c and Perl code
c: reduce the size of BOOT code generated by ExtUtils::ParseXS
d: reduce copy-paste repetition in the build system
e: reduce complexity and duplication of header macros by using static inline functions

2: Fixing bugs, much like Dave is doing. Given a moderate amount of communication about which general area each is working in, I don't think that there's much risk of duplicate work here. (And that would probably scale to a third person, before a proper manager would be needed)

However, fixing both "big" and "small" bugs would be useful. Big, because Dave will welcome the help; small, because it is good to get the total bug count down. In particular, I'd likely be able to look into problems that the release manager deems to be "showstoppers" for a stable release.

I'd like to review every use of I32 in the core, as I suspect that most are wrong - my hunch is that at least 90% should be one of U32, IV or STRLEN. I'd also like to review the entire PerlIO implementation. I don't expect to start on either of these tasks in this initial grant.

Bug fixing can be tracked by RT tickets being successfully resolved. Code review is harder, although it could be tracked by the number of RT tickets opened.

3: Ensuring that threads on perl5-porters don't stall, and questions don't go unanswered.

Often volunteer contributors, or would-be contributors, mail the list with questions or part finished work, stalled until their requests are answered. Some messages are easy for anyone answer quickly, so someone answers. Some messages are easy for particular people with the right knowledge to answer, so the message gets answered. But some messages aren't easy for anyone to answer quickly, so there is no reply, and a potential contribution or even contributor is lost.

It's not just newcomers or people round the periphery of Perl 5 development - several of the active committers write e-mails that request help, or that ought to generate discussion, but no-one has the time to think through the problem, so no-one replies. For similar requests where I have responded, to write my message has often taken about an hour of digging and prep-work, in order to write the reply that the original deserved. If this sort of work isn't covered by the grant, then it simply isn't going to get done, as it makes no economic sense to work on something hard and unfunded when something equally hard, funded and potentially more fun is also available.

This is hard to measure quantitatively, but I think that it's important to somehow cater for it. I wouldn't expect it to average out much over 10% of a week's work, or peak higher than 20%. The reporting structure means that it can be measured qualitatively - the grant managers and active core developers can compare the figure claimed with replies in the mailing list archives, and request clarification, deny part-payment, or even refer the grant to the board for termination, if appropriate.

4: Actually add features

The "success criteria" for new features are that

a: other people think that the plan is good
b: that the plan gets implemented

Currently the only features that I think would be beneficial to add are all at the internals level. Specifically

a: implementing and benchmarking Chip's "view" support at the API level
b: vtables for array and hash access, to permit
i) decoupling the "restricted hash" implementation from the SV flags
ii) removing the tied array/tied hash code from the common case
iii) a better implementation of sparse arrays
iv) flexibility for typed arrays and hashes as CPAN modules

Whilst working, I would also keep in mind how we might develop process and structure to keep things working well, if future funding would enable us to cover the costs of more than 2 or 3 people working on core maintenance.

For the grant, I'm specifically not proposing to

1: be a release manager. I think that current rotating volunteer system that Jesse put in place is working well.

2: managing the synchronisation of CPAN modules and interaction with their authors - what sane organisation benefits from promoting its best programmers into management positions?

3: act as language designer - I don't feel that I'm good at this.

4: take sole or principal responsibility for tasks that anyone could do, such as reviewing or applying general patches sent to the list.

Project Schedule:

I expect that I can deliver 400 hours of work in approximately 3 months. As described above in "deliverable elements", specific tasks in "project details" are examples of the types of things that I intend to work on. I certainly can't get all done in the first 400 hours, and it may turn out that other tasks are better use of TPF's money, in the opinion of myself, my grant managers and the active Perl 5 developers.

I am available to start work on this project immediately.

Bio.:

Of the top 3 contributors to Perl 5, I'm the only one still active, and the only one who has removed more lines of code than they added. I've shipped more stable releases of Perl than anyone else in the past 15 years.

As well as that, over the past 13 years I've

* Reduced the memory usage of most core data structures
* Reduced the runtime CPU usage by about 5%
* Replaced platform specific code with unified build tools
* Restructured extensions to a layout which is much simpler to maintain
* Devised and implemented the changes needed to be able to cleanly move modules from core to CPAN, and thereby removed Switch
* And along the way fixed many bugs.

Endorsed by: Jesse Vincent, Tim Bunce, Marcus Holland-Moritz

Amount Requested: $20,000

Suggestions for Grant Manager: Marcus Holland-Moritz, Ricardo Signes.

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

Recent Comments

  • idn: Ah crap, that should have been Jozef not Alberto.. read more
  • idn: Hi Alberto, Do you plan to import the existing RPMs read more
  • idn: This is an excellent plan getty! I'd vote for a read more
  • Neil Bowers: I think this is well worth funding (and more so read more
  • autarch.urth.org: The Perl community needs more well thought out and documented read more
  • autarch.urth.org: I'm all for improving ACT, and if the current maintainer read more
  • Jeffrey Ryan Thalhammer: This definitely gets my support. I'm thinking of putting on read more
  • Paul Seamons: While I like reading reviews, I'm not sure I'd pay read more
  • Jeffrey Ryan Thalhammer: tempire: It is probably impossible to do full justice to read more
  • Jeffrey Ryan Thalhammer: I'd love to see this proposal funded. Neil always writes read more

About this Archive

This page is an archive of entries from August 2011 listed from newest to oldest.

July 2011 is the previous archive.

September 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.

OpenID accepted here Learn more about OpenID
Powered by Movable Type 4.38