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.
If you have any questions, please feel free to contact Jeremy Fluhmann (fluhmann at perlfoundation dot org).
]]>Both parties have agreed to terminate this grant agreement. This will free up
Shlomi to work on other projects, and allow the Perl Foundation to use the
money to fund future grants.
Title:
svn.cpan.org - revision control for all of CPAN
Synopsis:
This project will create a universally addressable Subversion space for the Perl community. It will be populated with historical and ongoing CPAN releases.
Every CPAN author will be given a public version control repository, and may use a portion of it for any (reasonable) purpose.
Alternate views, such as mappings for each distribution, will be handled via the http namespace.
Benefits to the Perl Community:
Preservation of History
A uniform set of release tags for each distribution will benefit Perl users, CPAN authors, and downstream distributors (e.g. Debian) by providing a structured system for querying changes and performing bisection bug searches. It will also offer convenience to the module author or maintainer by providing rigorous and dependable tags in cases where the original release tag history may have been nonexistent or lost.
Future History
This system will give CPAN authors an easy path to start using version control, but no action is required on their part for the system to be useful. They may choose to import their existing tree, copy a tag as a starting point, or simply let the release history continue to automatically accumulate.
Discoverability
The filesystem-like nature of Subversion and the ability to use HTTP namespaces as glue provides a uniformly discoverable tree. A proxy configuration could allow some paths to point at external SVN servers. Even external, non-svn repositories can be found by humans via simply placing instructions in a text file. Formalizations may evolve with use, such as a standard 'see_other.yml' file or other conventions supported by client-side tools.
Addressability
Rather than downloading a tarball to examine its contents, users will be able to fetch a single file (e.g. META.yml) or obtain a directory listing directly from the svn URL.
Welcoming Experimentation and Collaboration
Giving every CPAN author a subversion space provides convenience to both new and existing authors. It encourages them to publish code early and often, getting feedback from the community as they go. By providing a common middle ground between local changes and CPAN releases, new ideas are more conveniently tried and shared.
Enabling Innovation
The normalized HTTP namespace and historical data can act as a foundation for many new tools and techniques. It is hoped that the system also creates new ways to search, new alpha-release channels for cpan clients and testers, a structured base for documentation patches, and enables various other interesting possibilities for the Perl community's infrastructure.
Deliverables:
Project Details:
One Repository Per Author
Previous attempts tried to fit the entire CPAN into one repository. It "fits", but the import must be monolithic and the ongoing administration and maintenance seems unwieldy. The repository would be roughly 4GB at over 100k revisions. This layout would be easily abused (accidentally or not) by requesting the full log or checkout. Further, any corruption (via corrupt bytes or the need to scrub a malicious checkin) would require a long dump/load and possibly extended downtime for all authors.
By breaking repositories at the natural "author boundary", most of the linearity of history and "diff compression" benefit is preserved. This scheme also allows for partitioning across multiple servers should the request load ever warrant it. The drawbacks of monolithic import and unwieldy size are traded for some complexity in cross-author issues.
The use of a single HTTP namespace will gloss over these issues for most users. Others may need to understand the boundaries (e.g. "http://svn.cpan.org/E/EW/EWILHELM/..." where the repository is at "EWILHELM" and the rest is in the httpd config.) But I believe that such issues will be minimal and, if necessary, can be handled by client-side tools (which are outside the scope of this proposal.)
Ordered, Tagged Imports from Backpan
The import process mainly involves organizing the tarballs and unpacking them in sequence with some svn actions. Early experiments show this to be I/O bound and suggest that it might yield well to some light clustering. The latest rethink based on per-author repositories helps here.
The initial import scheme has had a few dry-runs, but needs to be taught how to deal with more tarball oddities. It should also be more modularized and needs automated tests.
The import will use author id to identify the source of each tarball. Handling of multi-author distributions is still an open question, but such packages will either be merged based on the "02package.details" index or left to be addressed later.
It appears that the fsfs svn data can be hacked to enter the tarball timestamp as the commit date. If this does not work or there is not a better way, the tarball date will simply go in the commit message.
Iterations and Test Cases
The details of the import may require a few passes through the entire data set to get all of the kinks out of the procedure and get everything to look right. The initial version bailed after 17 hours, and a full load-in was estimated at 36 hours by extrapolating from that. The first task with the import tool is therefore to break the process into logged and restartable pieces so that trouble spots can be incrementally addressed while the run-through continues.
The troublesome packages and edge cases will lead to changes in the code, either being punted as unsupported conditions or fixes to the algorithm. In either situation, the edge cases will be collected into a list (or hash) for feeding the test suite.
Once all of the trouble spots in the backpan of packages have been addressed, the import may need to be run through one full pass to ensure that any changes to the layout have been consistently applied throughout the repositories.
Ongoing Imports
This will share some policy and procedure code with the initial import tools, but will have a different control flow (triggered rather than batch) and needs logging/etc suitable for unattended runs.
HTTP Namespace Experiments/Notes
Configuring per-dist views based on the module index should be relatively straightforward. Adding to such views in a running server might not be particularly elegant, but a 'graceful' restart should suffice. I plan to implement at least this one view and explore other possibilities. The main goal with this portion is to prove the namespace concept and whet the imagination of the community.
Documentation
POD/HTML documentation about the system and common use-cases will be provided. This will include an explanation of the access policy and recommended directory layout. Administrative/interface tools and APIs will be documented in POD.
Hosting and Maintenance
Initial hosting will be provided by me, though in the event of excessive traffic, I may have to throttle the bandwidth or restrict access to humans who request it. If such issues arise, the project will be a definite success and should easily find a permanent home with adequate bandwidth.
Publishing Results
The code, notes, and documentation will be available throughout the project in the following repository and I will blog weekly updates to use.perl.org.
http://scratchcomputing.com/svn4cpan
Project Schedule:
Estimated time: 8-10 weeks
Schedule: Starting around June 1, 2008
The schedule is more heavily loaded to the front because the main import will take a large chunk of concentrated work mixed with long run times and because CPAN is a moving target. I plan to work on the project 3-4 full days per week until the automatic imports are running. At that point, the gap between the history and "today" cannot grow and interruptions are not penalized by extended run times.
The final weeks are at a slower pace to allow for communication latency. The documentation will be driven by feedback and questions from the community. The triage and monitoring will be about one hour per day.
By funding this proposal, TPF will be allowing me to focus my development in large enough chunks to get ahead of the continually growing import task. In smaller increments of work, the run time overwhelms the free time per day and development gets postponed.
License:
All modules and utilities will be published under the Perl "GPL 2 / Artistic 1" license.
Acknowledgements:
Michael Schwern helped formulate the initial idea and has provided feedback and realism. Jesse Vincent had a basic version of an import tool and several helpful suggestions. Various members of the Portland Perl Mongers and the Perl community at large have provided useful encouragement and additional feedback, and chromatic says I can quote him as saying "I'm looking forward to it."
Scott Kveton, former director of OSU's Open Source Lab did pledge hosting and bandwidth almost two years ago. It is possible that the OSL is still willing to host this.
Bio:
I am the author of several CPAN modules, and a contributor to projects which include Module::Build, Test::Harness, Jifty, Moose, PAR, and Inline. I am also an active participant in several areas of the Perl community including wxPerl, parrot, perl-qa, and module-authors.
As president of the Portland Perl Mongers, I have organized monthly meetings (often with a speaker) for the past two years. I frequently give perl-related talks at pdx.pm, the local Linux group, and OSCON.
For Google's SoC 2008, I organized the community volunteers, submitted the org application and will be administering the TPF's 6 projects throughout the summer.
I was the architect and main developer for the dotReader open source book reader, founder of the VectorSection open source graphics format converter, and developer of the Perl-based imaging system responsible for A. Zahner Co's fabrication and installation of the patterned copper cladding on the deYoung museum in San Francisco.
Amount/Resources Requested:
$3000.00
DNS CNAME entry for svn.cpan.org
]]>Title:
Fixing Bugs in the Archive::Zip Perl Module
Synopsis:
Perl programs often need to manipulate .zip files. Archive::Zip (http://search.cpan.org/dist/Archive-Zip/) is a Perl module that allows a Perl program to manage Zip archive files without calling an external utility.
The Archive::Zip module, however, has some bugs which prevent it from generating fully-portable .zip files, that are handled correctly by all .zip file readers and manipulators. The project's main aim is to address the outstanding bug reports (http://rt.cpan.org/Public/Dist/Display.html?Name=Archive-Zip), by using
pyconstruct (http://pyconstruct.wikispaces.com/), which is a flexible framework for defining dissectors for binary formats in a declarative way.
Deliverables:
A version of Archive::Zip Perl module that will manipulate .zip files and a re-usable .zip file deconstructor.
Project Details:
Archive::Zip is a Perl module that allows a program to create, manipulate, read and write Zip archive files without calling an external utility. This programmatic approach is more robust than other approaches of calling external utilities, as their output is not easily parsable.
The aim of the project is to fix the existing Archive::Zip module. I will use the pyconstruct tool to compare the structure of .zip files produced by Archive::Zip with those produced by other utilities. pyconstruct will be used for the dissection. It is a generic analyser for file formats and protocols based on the concept of defining data structures in a declarative manner, rather than procedural code. Once I build the .zip file dissector, I will be able to compare Archive::Zip's outputs with those of other .zip archivers. Then I will be able to understand what Archive::Zip is doing wrong, and how to improve it.
The Archive::Zip Perl module will not depend on pyconstruct for its operation. pyconstruct will be used only for the comparison of binary .zip files.
Some of the currently outstanding bugs that will be fixed are:
* #22933: Properly extract symbolic links (http://rt.cpan.org/Public/Bug/Display.html?id=22933)
* #19502: Incomplete file (http://rt.cpan.org/Public/Bug/Display.html?id=19502)
Reproducing bugs is the major issue that can occur during the project. If I am not able to reproduce a bug, I will contact the bug reporter and get more details on how the bug had occurred.
In case of a setback, that is, inherent problem in Archive::Zip that cannot be solved, I will be able to deliver a .zip file parser in Perl. This parser will dump verbose information which will enable users to understand why certain .zip files are not fully-portable. This
knowledge will help in creating a new Zip archive module which solves the inherent problems of Archive::Zip Perl module.
Project Schedule:
The project will take 3 months. I can begin work immediately.
Bio:
I am doing my final year in Computer Science and Engineering at College of Engineering Chengannur, Kerala, India ( http://cec.ihrd.ac.in ). I am a member of the college website team. At college, I am the FLOSS Cell Chairman and have conducted classes and seminars on Free Software at my college as well as a nearby school. I am an active participant of technical events at college. I program in C/C++, PHP, Visual Basic and build web-sites for fun and profit. It has been a year and a half since I have fully converted to the GNU/Linux Operating System. At one period, I wrote some articles on GNU/Linux (http://slashmedia.wordpress.com). While having neglected doing that recently, I hope to revive that site soon. Currently I am maintaining a personal website at: http://drchost.com/~haggai/.
I have recently become interested in Perl. I have done a Webmin clone in Perl as part of college project. It helped me understand some basic Perl. I use the Vim editor for all programming.
Amount Requested:
$1,500.
Notes:
I have the approval of Archive::Zip Perl module maintainers: Adam Kennedy and Shlomi Fish.
Title:
CatalystX::Installer - A generic GUI deployment for catalyst applications
Synopsis:
Create a web application that provides a cross-platform generic GUI for setting up Catalyst applications. There is no command line version of this program since anyone who wants to use the command line can just edit the configuration files directly.
Benefits to the Perl Community:
Anyone who wants a friendly GUI with which they can easily setup, test, and automatically configure their catalyst applications will benefit from this project. The target user base for this application is people who would like to simplify and automate the installation of Catalyst applications onto their web servers. Currently, there is no accepted framework for providing GUI installers for catalyst applications; this module intends to provide a generic GUI for common web application use-cases, and a basis for extension where required. There is no command line version of this program since anyone who wants to use the command line can just edit the configuration files directly. I think this program could be classified as a new approach that is also an aggregation of existing tools and ideas.
Deliverables:
I plan to deliver a completed Perl module, called CatalystX::Installer, that provides a generic GUI for the deployment of Catalyst applications.
Project Details:
For CatalystX::Installer, the Movable Type setup wizard is used as an inspiration for its design. The main new idea of this approach is that the program will provide a generic GUI that works with most common use-cases for Catalyst applications, and provides a framework for extension for specialist use-cases.
This approach frees the Catalyst developers from having to design a setup wizard for their application(with the possible exception of some special cases) while also freeing the user from the hassle of having to use a different(or no) install wizard for each Catalyst application that he or she installs.
The solution involves either:
1) Adding the file script/myapp_setup.pl to the template for Catalyst
programs. For example: '$ catalyst MyApp' That command would create all of the files that it currently creates, plus 'script/myapp_setup.pl'.
2) Having the installer script running seperately such as: '$ catalyst MyApp; $ cd MyApp; $ catalystx-installer [options]' Where '$ catalystx-installer [options]'creates script/myapp_setup.pl and handles any special options. The file would contain a stand-alone server similar to script/myapp_server.pl. The administrator could then connect to this server and use the GUI to apply the configuration information(such as database info, fastcgi information, mod_perl, server address, login information, language, etc) when the application is installed on a server. The application developer could also customize this based on the requirements of his or her application. I would create a set of APIs that wrap around HTML::FormFu to make this process as simple as possible. For example, if the developer wanted to add an entry to get the preferred type of configuration file(YAML, INI, XML, etc), he or she could add some code similar to this to 'cscript/myapp_setup.pl'.
my $preferred_config_type=CatalystX::Installer::Forms::SelectionList->new();
$preferred_config_type->add({
'YAML' => "YAML",
'INI' => 'Windows INI File',
'XML' => 'XML',
});
This would allow the developer to easily customize the installer for his or her applications. A link to 'cscript/myapp_setup.pl' can be placed into the root directory during make dist.
When the user(server administrator) downloads the applications, she first extracts it, switches to directory, and then types the command:
$ perl myapp_setup.pl
It then starts by checking Makefile.PL to verify that all of the dependencies are installed. If all dependencies are not met, it asks the user if he or she wants to automatically install the CPAN dependencies, and also warns about any missing non-CPAN dependencies
that cannot be installed. Next, it verifies that the program runs correctly by doing the tests. After that, it runs make install. When make install completes, it will prompt the user to either enter a password or use a randomly generated password with which the GUI setup can be accessed(the user can change the password in the GUI setup).
The user can then access this server either from the local machine or a remote one, as long as they are using web browser capable of entering information into web forms. The password exists to prevent unauthorized access to myapp_setup.pl, it is stored in an encrypted location, and it is required for all subsequent runnings of myapp_setup.pl. The connection will also be encrypted with SSL/TLS in order to assure the safety of all data sent. When the GUI setup is complete, it will ask the user if they want the setup program to create a script that can be used to automatically enter the data that they just entered into the GUI setup program. This allows a user to clone a setup for multiple systems and of course a password is still required. Also, the script, if created, will only be readable by the user who created it.
CatalystX::Installer can be used for more than just installation; it can also be used to reconfigure an application that has already been installed. For example, if the user were to run myapp_setup.pl again, they could change the options they set up the first time. myapp_setup.pl would then save a backup copy of the original config file(s), and create new ones with the new options.
There are of course some uncertainties for this application. One of the main foreseeable problems for this application will be making the GUI generic enough where works for all programs, but not so generic that user or developer(s) needs to do a lot of customizations in order to satisfactorily setup the program. I plan on doing some surveys on the Catalyst mailing list to see exactly what options people want myapp_setup.pl to have by default.
Project Schedule:
Bio:
My name is Paul Cain. I am 18 years old and I am a Freshman(sophomore by the time summer starts) and I go to Kansas State University at Salina, where I have a 4.0 GPA.
I have been programming in Perl for about 2.5 years and I have read several books on programming in Perl. Of those books, Perl Best Practices was my favorite. I've been using Linux since 2004, although right now I do most of my work on Windows Vista with ActivePerl and Strawberry Perl.
For development tools, I started out using Activestate's ActivePerl as my Perl interpreter, but more recently I have been using Strawberry Perl due to its superior CPAN compatibility. I've also used standard Perl installation on various Linux distributions over the years. When coding Perl, I usually use a text editor with syntax highlighting such as Notepad++, Kate, or Gedit. However, the larger my code gets, the harder it is to manage with a simple text editor, especially when to code reaches 1000+ lines. I plan to switch to an IDE with a class browser, automated debugger, and other tools that will make the code easier to manage. Finally, I use dual-17 inch monitors in order to increase my productivity.
Generally I try to stay close to the coding standards set forth in Perl Best Practices because they provide a logical way to code that can be easily duplicated among multiple developers. For this particular project, I think that an Object-Oriented method of program design would probably be the best design method due to the size, complexity, and type of the program.
Most of the Perl programs I write are pretty short, but the largest program I've written was a personal project that ended up being about 1800 lines of code, much of which was for the GUI behavior. This particular program particular will most likely be larger than that, but I plan to use well-designed classes and strict adherence to Perl Best Practice's coding standards in order to keep my code cleaning, readable and easy to manage.
Amount Requested:
$3000
Project Title:
The Perl Survey - From "Pilot" to Production
Synopsis:
In 2007 Kirrily Robert organised and administered the Perl survey (http://perlsurvey.org) to provide a snapshot of the Perl community. In particular she made significant effort to recruit as many people as possible, resulting in a sample size of around 4500 responses.
While an excellent start for a design for a survey instrument, it can be improved in a number of ways. These are:
Benefits to the Perl Community:
Over the past few years, with the rise of other dynamic languages, Perl has often been described as having an "image problem" - misconceptions about the, readability, maintainability and general "hackishness" of perl code are commonplace. A more complete implementation and analysis of the Perl survey should help dispel some of this image problem, and provide a greater insight into the structure of the community. Although the Perl community is internally cohesive, there seems to be a problem with external communication.
Based on the aphorism 'know thyself' and the provision of high quality data analysis, this project should be seen partly as an attempt to move the discussion on within the community, and partly as a resource for people and companies that use or want to use Perl.
Deliverables:
Project Details:
Stage 1. Cleaning up of the perl survey data file.
A number of questions are represented in the Data::PerlSurvey2007 datafile as arrays. So for example the 'Programming Languages Known' hash key contains an array listing all the programming languages checked by that individual. From a statistical point of view this leads to a data file that is difficult to analyse. The correct practice is to create a dummy variable for every option that could exist. Again in terms if the 'Programming Languages Known' question, this means that for every individual, the language should be stored in a hash key rather than an array, and the value of the key should be 1 if the language is known to the respondent, and 0 if not. There is also significant extra work in folding the 780 responses in "Other programming languages known" back into the main "Programming languages known" before dummy variable coding. Unfortunately these responses will need to be processed manually so this stage is labour intensive.
While there are no other obvious problems with the data file other than this, experience suggests that smaller issues will occur. These should be much less significant than the problem with the "other programming languages" question.
Stage 2. Detailed statistical analysis
Once the data file is cleaned, we can then code each variable into the appropriate statistical data type (i.e. continuous, ordinal, nominal or boolean) in preparation for a more detailed analysis. The open source statistical software R (http://r-project.org) will be used for this analysis, and the scripts to generate the analysis will be documented and stored in a public version control repository.
The first step in a serious statistical analysis of the Perl survey data is to assess the best data reduction procedure to use. Two likely candidates are cluster analysis and multidimensional scaling. This work can be time-consuming due to the need to select and evaluate the performance of a variety of distance functions and clustering algorithms. This is worthwhile with the current data set, as there is a large sample of high quality data. This means that we have considerable statistical power. An examination of some of the demographic variables (including measurements of Perl community involvement) and examination of relationships between these and any
patterns found, are likely to prove interesting. So we can see how language preferences differ between "old-timers" and newer programmers, level of CPAN contribution and other community involvement.
This detailed analysis will lead to a much better understanding of the structure of the survey, and this in turn will lead to refinements of the questionnaire based on the data. Which leads to step three - refinement and extension of the existing survey.
Stage 3. Refinement of questionnaire
Once we have a clear picture of the structure of the Perl community, we can then refine the existing questions. For example, from my point of view, there are missing questions about the proportion of work time spent on programming and related tasks. Discussion with the community will reveal others, and the data reduction process from stage two will
also reveal other useful lines of questioning for future surveys. The job then is to find the shortest questionnaire for maximum benefit.
Stage 4. Development of Attitude Survey and/or Q methodology.
Attitude surveys are frequently used in social science to understand individuals and communities better. With careful design, these can be useful instruments with which to better profile the community. We propose to develop the questionnaire by analysis of the existing corpus of text in mailing lists and on the web with an intelligent
search strategy, and to read and code (tag with themes) relevant parts of this corpus. The second activity is to run discussions in person. I hope to obtain funding from elsewhere to enable me to travel to YAPC::EU in august to run a discussion session on the community, based on prior analysis of publicly available sources. Failing this, I will
be able to organise a session on IRC (including an attempt to recruit people who aren't IRC regulars, possibly with the help of CGI::IRC or similar). I will also run a second group at the Open Source Developers Conference in Sydney, Australia in December where Will also present a paper on the Perl community. This will have the advantage
that this is a multi-language conference where the local Perl community is well represented. Looking at external overlapping groups in conjunction with the in-group will provide useful extra information for framing an attitude survey. Experience suggests that this process should result in a well targeted 5 minute attitude survey.
I also mentioned using Q methodology. This is another clustering technique where participants rate a reasonably large number of statements on a continuum (actually a quasi-normal distribution - see the CPAN module for Statistics::QMethod::QuasiNormalDist for more details). Following this, correlation matrix between individuals is calculated and subject to principal components analysis and orthogonal rotation. This procedure results in quantifiable clusters of points of view, and the structure of subjective opinions. The decision whether to use this method really rests on the results of text analysis and group discussions, and depends on the nature of the
issues brought up in discussion.
Stage 5. The Perl Survey 2009
We would plan to run the second Perl Survey in April 2009 on hosting donated by Shadowcat Systems. Data analysis after this should be straightforward and quick based on the pilot work done on the first survey. There are a number of options for delivery of the survey. I may ask Strategic Data in Melbourne, Australia for a donation of their services, use the existing code that Kirrly Robert wrote, or use the survey management software which I am currently writing as part of another project. My own code is meant to be a generic solution to survey delivery, with ease of administration and encouragement of good psychometric practice, which I hope to be able to release under
an open source licence.
I'd anticipate that the survey should be run at 18 month to two year intervals following this.
Project Schedule:
Stages 1 and 2 Immediate to July 2008
Cleanup and statistical analysis of 2007 Perl survey results. Plan to release report on analysis for July in order to provide basis for stage 3.
Stage 3, August 2008 to December 2008
Discussion groups and interviews, particularly at YAPC::EU and OSDC.au. Qualitative analysis of this data for reporting, and incorporation into attitude survey.
Stage 4, September 2008 - January 2008
Analysis of interview/discussion data, and development of attitude survey and/or Q sort.
Stage 5. Run the second Perl survey through February 2009, with reporting and analysis ready by April 2009.
Biography:
I have been using Perl for research data management, visualisation, analysis and collection since 2002. In 2006 I became involved in the Catalyst project, and am currently the documentation manager. I was editor-in-chief for the 2006 and 2007 Catalyst Advent calendars and I was closely involved in the development of the Catalyst tutorial.
I have ten years experience of questionnaire design and analysis in health care and management research settings. I have tutored statistics at undergraduate and postgraduate level to students in science, psychology, medicine and marketing. A selection of my publications (with full text) are available at: http://xrl.us/bjwd7
(this does not include current publications in review, pre-2003 articles, and some conference papers).
I am currently trying to develop a substantial research project on open source communities, project viability and aspects of commercialisation. This is an extension of the work that I was involved with on Australian cross-sector R&D organisations from 2003 to 2005. The Perl survey is related to, but separate from my larger research programme.
Amount Requested:
$3000
Notes:
I have been given maintainership of this project by it's originator. The IRC transcript is below:
00:52 ! Skud [n=Skud@nat02.sfo1.metaweb.com] has joined #perlnet
00:52 < Skud> hihi
00:56 < kd_the_realone> hey Skud
00:57 < kd_the_realone> Skud: I'm applying for a tpf grant to do some significant work on the perl survey
00:57 < kd_the_realone> really I just need either your blessing to be doing this, or for you to hand me maintainership of the project
01:04 < Skud> hi kd
01:04 < Skud> kd: yes, please do it
01:04 < Skud> i will happily hand you maintainership
01:04 < Skud> was going to look for someone to take over anyway
NAME:
Improve POE::Component::IRC
SYNOPSIS:
I will improve POE::Component::IRC1 by overhauling its test suite, adding more features, fixing bugs and writing more documentation.
BENEFITS:
PoCo::IRC is the most modern IRC client module for Perl out there. It is used for many applications, mostly IRC bots. Users will greatly benefit from better test coverage, added features, and bug fixes. New users will also benefit from better documentation.
DELIVERABLES:
DETAILS:
PoCo::IRC currently does not report any progress on DCC file transfers (except for success and failure). One way to implement that would be to send a POE event periodically, after every sent/received chunk of DCC data. Registering for this event will allow a GUI client to update a progress bar for example.
Bandwidth throttling of DCC transfers is missing as well. This might be done by subclassing POE::Wheel::ReadWrite to add rate limiting capabilities. If I manage to do that in a very general way, I will put that code into a separate module to make it easy to use with other POE-based code, or patch POE::Wheel::ReadWrite. I will have the rate limit be a configurable value passed to POE::Component::IRC's constructor, as with the DCC ports.
PoCo::IRC does not have sufficient test coverage in my opinion. Devel::Cover reports a total of ~39% coverage. I will add to and improve the test suite, to discover possible bugs to fix and further ensure code quality. I'm aiming for at least 65% coverage.
PoCo::IRC has been criticized for being a little hard to use at first due to unclear documentation. I recently started writing the PoCo::IRC Cookbook, which provides working example programs with documentation. It currently lists 11 recipes, of which 4 have been written. I will complete at least 3 of the unwritten recipes (or new ones).
In the event that I fail to accomplish some of my objectives, effort on any other objectives will not have been wasted as they do not depend on each other.
SCHEDULE:
Weeks 1 & 2
Weeks 3 & 4
Weeks 5, 6 & 7
BIO:
I am a 22 year-old student from Iceland. I have been refactoring, fixing bugs and adding features to PoCo::IRC for the last couple of months3, during the course of writing an IRC bouncer4 based on it. I am now one of PoCo::IRC's co-maintainers. I have not been very involved with other open source projects aside from occasional patches and bug reports to various pieces of software that I use. I have a very good grasp of Perl and feel confident that I will be able to do everything I have listed in this proposal.
As for development tools, I usually go for vim or gedit for code writing, then the command line and perl(1) for the rest. Computing power is graciously provided by my trusty old Dell Inspiron 8600 laptop. Perl is my favorite programming language (so far), in large part due to its "postmodern" nature5. I've read quite a few books about Perl, my favorite being the Camel book, closely followed by MJD's Higher-Order Perl.
AMOUNT REQUESTED:
$2,000.
REFERENCES:
Project Title:
DBEditor
Synopsis:
DBEditor implements a CGI-based database editor. It allows you to very quickly implement a basic table editor by simply stating table data in configuration files (tools are provided to create the configuration files from your existing tables SQL schema).
Set up your database config info:
mv db_template cgi-bin/db_lib
vi db_lib/dbconfig.pl # Edit database connection settings
vi nav_lib.pl # Optional: Customize your nav bar, add links to many tables, etc
Set up an editor for your "contacts" table:
cp -rp template cgi-bin/contacts # template contains edit_items wrapper, config.pl, plugins.pl
vi cgi-bin/contacts/config.pl # Edit table schema
Point browser at:
http://www.yourdomain.com/cgi-bin/contacts/edit_items
You can then quickly add functionality using plugins (provided as subroutines in plugins.pl), for example:
It is easy to add more "plugin points" in DBEditor for future needs.
Benefits to the Perl Community:
DBEditor provides an extremely simple and fast foundation for a web application. Setup and learning curve is much faster than Catalyst (about 1 hour for a new user to get a simple table editor running), and it's simpler and more stable than Jifty (DBEditor has been around longer and specializes in editing database tables). It provides the means to set up a simple web app to edit a database that can be easily expanded into a more robust application.
Deliverables:
Review and re-write existing code in DBEditor.pm to:
Complete the existing documentation:
Project Details:
DBEditor was originally written as a set of CGI scripts. A copy of an "edit_items" script had to be placed in each directory and had accompanying config and plugins files. The main script code was then moved into a perl module and the "edit_items" script replaced by a wrapper that contains: "use DBEditor; &process();".
The module is functional and in use in several web sites I maintain. However, the code and documentation is not "clean" enough for me to release to CPAN. It also needs to be made into a true OO module to be compatible with mod_perl. These are tasks I'd like to do, but I haven't had sufficient motivation since the module functions suitably for my needs. Given the module's evolution, these are not minor changes. The code will need to be completely reviewed and revised, and proper documentation will need to be written so that new users can utilize the module easily.
Project Schedule:
Based on my current workload, I would be able to deliver within 1 month and begin work within 1-2 weeks of grant approval.
Bio:
I have been programming perl since the early 90's, and have been programming in general since the late 70's (when I was 8). My father owns a computer company in what's now called "Silicon Valley", so I grew up around computers. In 1996 I wrote a web-based project management system that I use to this day in my consulting work. I have also authored several CPAN modules including WWW::Myspace, WWW::CDBaby, and WWW::Sitebase to help musicians promote themselves online and access their CD sales data.
Amount Requested:
$2500
Title:
Extending BSDPAN
Synopsis:
Refactor the BSDPAN module into a generic and extensible solution for bridging CPAN with UNIX packaging systems.
Benefits to the Perl Community:
The wealth of freely available code CPAN represents is one of the Perl language's greatest strengths. Tighter integration of this resource with a given operating system's native packaging system would give Perl a unique advantage over Ruby, Python, etc. while making it more accessible (and maintainable) to users.
Deliverables:
Project Details:
BSDPAN was conceived (and written) as a glue module for interfacing CPAN module installation with the FreeBSD operating system's native package database. Blurring the distinction between CPAN and the FreeBSD `ports tree' in this fashion offers several advantages: modules honor environment variables such as $PREFIX automatically, and the user can query and manipulate them as they would any other software package.
I propose to expand BSDPAN into a more generic solution for bridging the gap between CPAN and the myriad of packaging systems in use today. This would include fleshing out BSDPAN's nearly nonexistent body of documentation, factoring out FreeBSD-specific code to a submodule accessed through a consistent interface, and adding support for
Module::Build.
Project Schedule:
Expected timeline: Approximately three months, or the duration of my summer holiday, whichever comes first. Work will begin the week of May 26th (firm date to be decided upon receipt of finals schedule).
Bio:
I've worked with Perl in some capacity for a little over eight months, and have dabbled in projects such as Catalyst and POE. I have significant prior experience in this problem domain, having the pfSense project's package system virtually from scratch several years ago. This system, written in PHP, ``wrapped'' FreeBSD package files for integration with a pfSense firewall's online administration interface, logging, remote administration tools, etc.
Amount Requested:
My work as funded by this grant would constitute at least some part of my summer employment, and as such I feel proposing an hourly wage rather than set milestones would be most prudent. Assuming an average of 15 hours of work per week at $15 per hour, two months of work could be funded for $1800.
Notes:
Anton Berezin, BSDPAN's maintainer, was contacted over IRC and gave his consent for the project.
Project Title:
Make localtime() and gmtime() Work Past 2038
Synopsis:
Prevent the Y2038 bug from effecting Perl users. This means make localtime() and gmtime() work for times beyond 2038. Do this regardless of the state of the system C libraries.
A working solution, in C, already exists. This grant is to finish the portability issues, write additional tests and change perl to use the repaired C library.
Benefits to the Perl Community:
Outlined here in detail. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-02/msg00040.html
Perl has traditionally shielded programmers from the limitations of C. The idea that time ends at 2038 is a ridiculous notion to anyone but a Unix C programmer. When localtime() returns the wrong date programmers will blame Perl, not C, resulting in another ding against Perl.
We can instead turn this into a PR win for Perl. Similar to the publicity for being one of the safest Y2K languages, Perl can be one of the first Y2038 safe languages.
Deliverables:
64 bit localtime/gmtime
Provide a patch for Perl which...
Project Details:
Perl will have to bundle it's own 64 bit clean localtime() and gmtime() implementations.
There is one OS specific component to localtime() which will need to be duplicated or gotten by other means and that is how to adjust for the current time zone. The scalar value of localtime() and gmtime() is not effected by locales. This problem has been solved. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-02/msg00259.html
The usual sorts of system compatibility problems will need to be resolved. A discussion of the issues has been started here. Much of the information is already gathered by Configure. Andy Dougherty has said he'll work on the rest. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-02/msg00277.html
localtime() and gmtime() will still be limited by the size of Perl scalars. For 32 bit systems this means NV limits which is about 2**47 or about 4 million years in the future. With 64 bit integer scalars it should be able to go all the way out to the limit of a signed long long or 2**63 which is something like 300 billion years. However, since we're still using the 32 bit tm struct and tm.tm_year is a signed int so the practical limit on 32 bit systems is about 2 billion years in the future which I'm happy with.
Permission has been gotten from the original author of the 64 bit localtime code to use and modify it in Perl without a binary attribution clause.
Project Schedule
I will be available to work on the project after June 20th (post YAPC::NA).
The first, speculative phase is already complete. This involved writing the 64 bit clean localtime/gmtime C functions which work on 32 bit machines and shoving it into the perl core.
Second phase is cleanup of the patch with perl to make it play nice with Configure and not leak memory, etc. This will require the assistance of p5p and those who know Configure, perl and C.
At this point it works well enough to be shipped in bleapderl. This is a long back and forth process requiring lots of input from many people on many different machines. A lot of time will be spent waiting for feedback. It is anticipated this will take at least one
month, probably two.
Third phase is to improve the C functions.
These parts are relatively straight forward and should be solved in two weeks. They can be done in paralell with the 2nd phase.
Finally, backport into 5.10 and 5.8. This should be trivial.
The project is considered complete when maintperl contains a 64 bit localtime.
The earliest date for completion is July 26th. Latest is August 18th. It is not a coincidence that these correspond with the end of OSCON and YAPC::Europe. They provide opportunities to get some intense hacking done on any hanging issues that might be holding up the process.
Bio
Although my C skills are far from ideal for solving this problem, I seem to be the guy who cared enough about this problem to push it through and write a complete implementation. I work as an independent contractor and will be working half time for the summer in anticipation of working on grant work.
Andy Dougherty and Jan Dubois have expressed interest. Andy knows Configure and Jan knows cross-platform porting.
Amount Requested:
Total: $1500
$1000 for myself to write tests, preliminary perl core code patches and ensure the remaining deliverables get finished.
Because my expertise is not up to snuff in some places, I would request another $500 to be dispersed to folks helping out, mostly with the Configure and porting issues and necessary cleanup, to ensure the work gets done. Should this money not be necessary it will be returned.
]]>Project Title:
CPAN Stability Project
Synopsis:
The CPAN Stability Project is intended to improve the usability of CPAN over long term use by providing a way to choose between safe releases vs newest releases as well as to better guarantee that upgrading will not break anything. It draws heavily on Debian's release management and tiers (unstable, testing, stable).
This is a combination largely of known problems and previously proposed solutions into one overarching vision of stability with flexibility by adding...
Benefits to the Perl Community
The intent is to allow everyone to safely and automatically keep their CPAN modules up to date.
CPAN is Perl's greatest asset, but it is not used widly enough because there is only one way to keep up to date on CPAN and that is to install the latest version. This is a crap shoot, and for large dependency chains there's a very good chance something has broken today. The CPAN Dependency Checker illustrates the problem. http://cpandeps.cantrell.org.uk/
This will allow large-scale CPAN users to feel and be safe when using CPAN modules while still keeping up to date, while still allowing those who value rapid development to get the latest versions and servicing everyone in between.
The CPAN Stability Project eases the "dependency hell" problem of a broken dependency bringing an install or upgrade to a halt.
Deliverables
The project is split up into four major pieces, Testing Dependents, Indexing and Release Metadata. Please see the wiki page under Project Details for details of each component.
The deliverables have all been specified as use cases describing what new abilities will be available, rather than how it will be done. This is so the implementation can evolve without having to renegociate the grant, and so in the end the Perl Community gets their intended benefits.
Testing Dependents
Given a CPAN release, a user must be able to...
without installing the new release.
It is intended that these additions be available inside a CPAN shell, but initially they will be written independently to rapidly prototype the problem.
Though it will attempt to work without it, this phase will operate best with a local database of installed releases and one may be developed during the process.
This phase will likely depend on the Complete Index.
Release Metadata
The ability for release authors to document, via META.yml...
The ability for the indexer to...
The ability for the user to...
It is intended that these additions be added to the META.yml specification, but initially they can be added as 3rd party defined keys using the provisions for this in the META.yml spec.
It is intended that Module::Build and ExtUtils::MakeMaker have the ability to emit these new keys. If not, Module::Build users have the ability to add their own META.yml keys and it is intended that MakeMaker gain this ability soon.
This phase is largely independent of the other phases.
Complete Index
The ability for an indexer to create and updated...
The ability for a user to...
Tiered Indexing
The ability to generate and keep up to date...
The ability for an indexer to...
The ability for release authors to...
The ability for a user to...
It is intended that this all coordiante with PAUSE. Because of the complexity and age of the PAUSE code, it is intended that initial implementation will be with a new, prototype indexer. Should coordination with PAUSE not prove feasible, for whatever reason, or should it prove complex enough that it endangers holding up the project, the prototype indexer can be put into production independent of PAUSE. It would publish new indexes indepenently, but still remain in sync with PAUSE. Users and CPAN clients could use these independent indexes to talk with existing CPAN mirrors.
This phase can operate independently of the other phases. Without the Release Metadata all releases are simply considered Untagged.
Project Details
Details of the project can be found here. http://www.perlfoundation.org/perl5/index.cgi?cpan_stability_project
This project is a combination of several smaller, related grants. ambs advised that I should combine them. If the project is too large it can be split back into the smaller stages.
This project works best when coordinated with...
Project Schedule
I will be available to work on this project after June 20th.
Scheduling for this project is difficult as adapting PAUSE and the CPAN shells can throw the whole thing off. The independent prototypes can be scheduled with more certainty.
In the interest of getting this grant in before the 2008 Q2 deadline, I must leave off a schedule.
Bio:
Michael G Schwern will be doing the primary work. He has been programming Perl for over 12 years. He has written, maintained or been heavily involved in all parts of the CPAN module installation process. As maintainer of Test::More and ExtUtils::MakeMaker, at the very root of the CPAN dependency tree, he is acutely aware of the problems involved in keeping CPAN stable. He is currently working as an independent contractor. His work schedule for the summer is open in anticipation of being awarded this grant.
It is intended that the project coordinate with...
Amount Requested
$9000
Is this amount is too large for this round of grants, the project can be split back into the following pieces...
Complete Index: $2000
Dependent Testing
* w/Complete Index: $4000
* Tiered Indexing: $4000
Release Metadata: $1000
Additionally, as this project would be of great interest to any Enterprise level CPAN users, it is possible that several companies could be found to match the TPF's funding.
]]>Project Title:
Test::Builder2
Synopsis:
Write a new, incompatible version of Test::Builder (in a new namespace) to improve the architecture and support desired features which Test::Builder does not or cannot. Make sure that both Test::Builder and Test::Builder2 based testing modules can work together.
Benefits to the Perl Community:
Test::Builder underpins 80% of the tests on CPAN. http://www.nntp.perl.org/group/perl.qa/2008/01/msg10172.html
Its limitations become everyone's limitations. It's done a very good job adapting the last six years, and testing has become more sophisticated in that time, but age and backwards compatibility holds things back. There are a number of desired features which Test::Builder cannot support, such as end-of-test actions, without radically altering how tests are built.
Another desire is to make Test::Builder "subclassable" to override its behaviors. This is currently not possible and a simple subclass is unsafe. A more sophisticated system will be necessary and requires some careful thought.
Deliverables
Project Details
Much can be learned from chromatic's Perl 6 implementation of Test::Builder.
Because this would be an incompatible API change, it would have to go into a new namespace. Probably Test::Builder2.
There's a good chance much of the changes having to do with turning Test::Builder2 into an aggregate will be able to be backported to Test::Builder. Some are necessary, such as sharing single plan, output and test counter objects.
Project Schedule
I will be availble to work on this project after June 20th.
There are three major stages...
Much of the work on Test::Builder2 will be figuring out what people want to do with it and what the API will be. The code itself is not that hard. An alpha release can be coded quickly to begin getting feedback and have the API worked with.
Stabilizing the API and feature set will require a long iterative feedback process with test module authors and many alpha releases and much discussion. This is necessary so as not to wall off the Test::Builder2 API into supporting a bad design decision. As such, there is a long period built into the schedule before the first stable release.
Porting Test::Builder to Test::Builder2 is the final declaration that Test::Builder2 is stable and usable. This effectively "throws the switch" moving CPAN over to Test::Builder2.
If the project starts June 20th, the "at best" schedule is...
I must reiterate, most of the time in the schedule is to gain feedback, form use cases and allow the API to gel.
Bio
I wrote Test::More and maintain Test::Builder. I've been at the center of Perl testing for the last six or seven years.
I work as an independent contractor and have cleared my summer schedule to be able to provide at least 20 hours of work a week on TPF grants.
Amount Requested
$3000
Project Title:
Automatic INSTALL.txt generation
Synopsis:
Write a module which can automatically generate Perl module installation instructions. Integrate into Module::Build and ExtUtils::MakeMaker.
Benefits to the Perl Community
Most Perl modules come without module installation instructions. At most they might include the "make" mantra. Figuring out how to install a module, its prerequisites and how to get it to install into a different location than the system directory can be daunting to a newbie.
By making the generation of an accurate INSTALL.txt for modules simple and easy for authors, more modules will include installation instructions and Perl modules will be easier to install.
This makes CPAN modules more accessable, helping with a user through the first ten minutes of trying to use CPAN modules.
Deliverables
First stage is to write a prototype module which can do the following...
Then add support for this to MakeMaker and Module::Build.
NOTE: It may be easier to skip the independent module and simply code it as part of Module::Build and then port to MakeMaker. This is because a lot of the information which the prototype will have to probe for may already be known by Module::Build.
Project Details
Many moons ago I wrote a program to do this called mod2readme. http://schwern.org/~schwern/src/mod2readme
Project Schedule
I am available to begin work after June 20th. This is a straightforward, low risk project using technologies I know well.
Everything takes longer with MakeMaker.
If the project starts June 20th, then the schedule looks like this:
The project is considered complete when the deliverables have been integrated into Module::Build's and MakeMaker's trunk.
Bio
I maintain ExtUtils::MakeMaker and have worked extensively on Module::Build. I think about usability problems in perl.
Amount Requested
$500