I couldn't resist the title given the date, but this isn't actually a joke :)
Yesterday Ovid put out a call for grant applications, and ideas for things that could be sponsored.
I wrote in mentioning a project that needs to be done, but which I don't have the time or qualifications to handle. The grant committee is interested, and so I've been asked to put out a call for anyone interested in spending a month or so on TPF's dime.
In response to my CPAN-capable Windows Installer challenge in January, Carl Franks responded with Vanilla Perl, which is an installer containing MinGW, dmake, and core Perl compiled with them.
Vanilla could be classed as a research distribution. It allows people working on the Perl toolchain itself to work on Win32 compatibility, it provides a way to examine how the Perl core interacts with Win32.
But it isn't really useful to anyone doing development, and is still loaded with bugs, although both David Golden and myself have been working in bits and pieces to slowly squash the bugs in it.
What would be much more useful would be a different flavour of Perl, a distribution tentatively code-named Strawberry Perl.
The purpose of Strawberry Perl is to expand on Vanilla, bundling in all of Bundle::CPAN, as well as bundling some strategic upgrades of some dual CPAN/core modules that have had Win32-related upgrades since 5.8.8 was released.
The aim is to provide CPAN authors a Win32 Perl platform that is similar in use and style to the Unix Perls, to make it easier for them to port to Win32, and to provide a suitable basic Perl platform for experienced Perl developers that prefer to install from CPAN, instead of using binary packages.
Because nobody currently working on Vanilla can contribute very much time, the grant would involve the TPF paying someone to take responsibility for the creation of delivery of the first production release of Strawberry Perl.
This means tracking and keeping an eye on ALL of the bugs that are preventing the release, hunting down and diagnosing bugs, creating patches to fix them when the module's author isn't very Win32 savvy or doesn't have time to fix them, taking co-maint bits to release new versions of modules where the author is awol or doesn't have time to do releases, and generally dealing with any bits and pieces holding up Strawberry Perl.
This is the direction Vanilla is moving anyway, but currently it's moving in dribs and drabs, and it would be great to have someone push it through to completion.
Interested parties should have experience with both Win32 and Perl, and given the nature of the task, will need to play well with others.
So how about it, want to be funded to work on a Perl distribution for a while?
Note this is a grant, not a job, and so the rules of the grant process still apply. But the grants committee would look highly favourably on anyone interested in this project.
I'm interested. I have a lot of Perl programming experience (been programming Perl since 1996 and have over 20 modules on CPAN and many other Perl projects), and also programmed for Win32. I also have a lot of experience in C Programming.
I'm not too familiar with the perl5 internals/XS/API, though, but I'm a smart guy and can learn them.
If you're interested in giving me the grant, you can contact me and we'll discuss it further.
Homework
Aristotle on 2006-04-01T19:34:05
Re:Homework
Shlomi Fish on 2006-04-01T19:44:09
Thanks! It wasn't linked from the original post.Re:Homework
Aristotle on 2006-04-01T19:52:15
It is linked from Ovid’s post, which is linked from the original post.
I contact the guy that did the PXPerl distro. It is really good already but he is a student looking for money. Hopefully he will apply and be accepted.
http://pxperl.com/Re: Hopefully
gpean on 2006-04-02T16:52:08
Hi, I am the author of PXPerl. I'm indeed interested in this. I am going to (re-)write a proposal to TPF. Perhaps I'll be more successful this time:) Re: Hopefully
sigzero on 2006-04-02T19:34:01
If I could vote I would vote for yours.Re: Hopefully
Alias on 2006-04-03T06:59:21
Are you planning on resubmitting for PXPerl, or attacking this by starting from Vanilla and going from there.
Because in trying to work on PXPerl's build stuff, before we had to abandon it and look for fresh approachs, I was getting comments that some of it was doing some very crazy and evil thing.
One of the key points of my challenge to find a replacement for PXPerl was that it had to be reproducable. Someone else needed to be able to come along and keep maintaining it, so that we didn't suffer from the risk of author abandonment.
So what are your plans?Re: Hopefully
gpean on 2006-04-03T11:54:59
I am completely aware of what PXPerl is lacking: everything is made by hand and that's definitely not convenient nor contributable nor reproducable. But when I started PXPerl, I just didn't want to start another more ambitious project that I would forsake 2 months later, unfinished.
The current drawback is that, justly, practically no one can contribute to it, and anyway I don't want to because it's way too crafty (and I am curious about your "evil" thing... I haven't had such feedback).
Given that, I started a big automated build script (with enhanced chained modules installation etc.) for PXPerl, so that everyone would be able to make its own PXPerl at home, and so that everyone can contribute to it.
It is perhaps 60% finished, but I quite stopped creating it in november of last year.
Perhaps some parts could serve for Strawberry Perl...
It is a pity that TPF didn't even contact me or replied me to my grant request. No answer to why my application was rejected, no encouragement, nothing. Now it's fostering a brand new project, with quite exactly the same goals as PXPerl... I hope at least that I contributed to the idea, or to show that people were needing this.
So, no, I won't make PXPerl a concurrent to Strawberry Perl, which is more clean. I am currently in fog as regards PXPerl. I am tempted to put an end to it, in an official manner, because I haven't done anything for it since a couple of months. I guess that with the announce of this new project, the decision will be more easy.
Now, as regards my application for Strawberry Perl, I am wondering how much time do you expect from an applicant for this, eg. monthly (bounds)? How does the grant allocation work for this kind of "job"? per hour, per task? I guess that you will be choosing the one that request the smallest amount in the application form.Re: Hopefully
Alias on 2006-04-04T06:44:00
I believe some of the comments I got mentioned some really ugly hardcoded build paths, that might it very difficult to even reverse engineer the improvements to it.
I wouldn't be too surprised that you didn't hear, the rule of complaints is that you only ever hear 1 out of 10 in any case, and I don't know of more than 3 or 4 people that looked at the internals.
PXPerl certainly helped I think, there's nothing like having a prize laid out before you, almost completed, and then have it snatched away, to drive people to industriousness.
I believe someone linked to the grant procedure above, but generally it is NOT based on market rates. The amount you ask for it intended to be based on what you would need to complete the task.
Since the point of this is to have someone working full(ish) time on this to help drive the completion, I imagine you'd be asking for what you think you need in order to do that.
As long as the grant amount stays within the $5,000 limit, and is commensurate to your needs, I don't think the grant committee are going to be voting based on penny-pinching.
Certainly if one person was asking for $4,000 for two months, and the other was asking for $500, I'd be asking if the latter isn't just fooling themselves, and might abandon the work.
They are less concerned about a few dollars, rather than the person will actually execute, and that they are not going to pull out. They want results, not a lower headline figure. And they'll approve whoever they think is the most likely to deliver.
Re:Simon says...
Alias on 2006-04-02T06:50:37
And indeed the CamelPack is almost the ideal short term solution.
For anyone currently wanting to do Windows developer, for now you should be using that.
Vanilla -> Strawberry is more of a "CamelPack done right", without taking all the shortcuts. Better for the long term, even if it doesn't work now.Re:Simon says...
jordan on 2006-04-02T20:26:43
Oh, I see now. Both Vanilla Perl and Strawberry Perl are part of the CamelPack Project.
I thought this sounded like the same thing that I'd just read about on Simon's Blog...
Re:I'd like to help
Alias on 2006-04-03T09:37:39
Hi there!
And thanks for the offer.
I'm hoping to sort out a win32.perl.org wiki shortly, and I expect we'll have some sort of bug tracking page there.