[epo-core] Grant Proposal

[Jay Kuri]

Hey all,

I'm in favor with one proviso.  Dist::Zilla does not contain support for 
sharedir type data (as in not just executables).  I've looked at 
Dist::Zilla a number of times and this issue is glaring and has caused 
me to fall back to older dist systems.  Without this feature, I won't 
use Dist::Zilla, so it has limited to no value to me. If we can include 
that as part of the grant, I'm on board.

Jay



Mark Keating wrote:
> Hey all,
>
> RJBS has put forward the following grant proposal for us to consider
> (below) we should work out if it is something we should do, and if we go
> for the full grant money he has asked for.
>
> Kind regards
>
> Mark
>
> -----------------
>
> =head1 Improve Dist::Zilla's Tests, Documentation, and Structure
>
> =over 1
>
> =item Name:
>
> Ricardo Signes
>
> =item Email:
>
> C<rjbs at cpan.org>
>
> =item Amount Requested:
>
> $2000
>
> =back
>
> =head2 Synopsis
>
> Dist::Zilla is a tool that helps Perl programmers build distributions
> for the
> CPAN. It eliminates boilerplate, handles packaging, interfaces with
> changelogs
> and version control, improves prerequisite management, and generally
> makes it
> easier to be a CPAN author. This grant will fund work to make it easier for
> new users to adopt Dist::Zilla and for Dist::Zilla itself to be more easily
> extended, maintained, and understood.
>
> =head2 Benefits to the Perl Community
>
> Dist::Zilla makes the CPAN better. More code can be released because the
> code
> to do so is greatly lessened. The code that is released can be of a higher
> quality because more time can be spent on the code rather than the
> packaging.
> It can also improve the lives of CPAN authors in general: if you don't
> want to
> spend the time that Dist::Zilla saves you on writing more code, you can
> spend
> it on anything else you like: skiing, sleeping, or eating ice cream.
>
> =head2 Deliverables
>
> =head3 reusable testing tools
>
> Dist::Zilla and most of its plugins (both core and otherwise) are not well
> tested, because testing it is tedious. This could be greatly improved by
> writing a few test classes or mock plugins.
>
> Estimated time: two days
>
> =head3 extensive testing of the core
>
> The reusable test tools will be put to use (and thus proven useful) when
> tests
> are written for all the core functionality. These tests may not be
> exhaustive,
> but they will be extensive and will be written with the goal of making
> contributors feel that they can trust the test suite to catch most
> regressions.
>
> Estimated time: four days
>
> =head3 simplification of the command line tool's code
>
> Right now, a number of hookable events are defined only in the code
> implementing the F<dzil> command, which too tightly couples the main class
> behavior to the command line tool. As much as is possible, the
> App::Cmd-based
> code for F<dzil> will be turned into a very thin wrapper around
> Dist::Zilla's
> methods.
>
> Estimated time: one half day
>
> =head3 event structure for distribution creation
>
> In other words, plugins will be able to attach more behavior to
> distribution
> creation, to create new source code repositories, start files, and so on.
>
> Estimated time: one half day
>
> =head3 improved prerequisite handling
>
> This will include improved methods for specifying versions required by
> allowing
> shorthand identifiers for the latest version of a prerequisite, or the
> version
> with which the author has tested.
>
> (If the META.json 2.0 specification is sufficiently finalized by the
> time this
> work is approved, the core Dist::Zilla prerequisite system will be
> improved to
> match it. I am familiar with the proposed changes to META and have a
> plan for
> how to support them.)
>
> Estimated time: one day
>
> =head3 improvements for authoring distributions containing XS
>
> I do not write XS code or C, but a number of users of Dist::Zilla do and
> have
> asked whether I can improve Dist::Zilla's ability to accomodate them.
> Florian
> Ragwitz has given me some ideas on how to do this, and I would like to
> carry
> out his plan so that Dist::Zilla does not discriminate against XS authors.
>
> Estimated time: one half day
>
> =head3 documentation: improved new user's guide
>
> This will extend and supplement the existing Dist::Zila::Tutorial, starting
> from the position, "So you want to release code to the CPAN..." There
> will be
> a Pod version shipped with Dist::Zilla, but also an HTML document and
> slidecast
> to more clearly walk new users through the process.
>
> Estimated time: four days
>
> =head2 Project Schedule
>
> I can begin work immediately upon receipt of first-third payment. I predict
> about ten or twelve Saturdays of work. (If payment were received before the
> holiday season, there might be some weekends on which no work is
> performed.)
>
> The figure quoted about, $2000, reflects about twelve full days at the very
> reasonable rate of $20 per hour.
>
> =head2 Bio
>
> I'm RJBS on the CPAN. I have released or adopted hundreds of modules, and
> Dist::Zilla is the result of my own desire for a tool to make
> maintenance of
> CPAN distributions simpler. My previous TPF grant-supported work on
> Pod-munging tools was also in furtherance of making it easier to
> maintain CPAN
> distributions. That work was completed without problems and the released
> code
> has been succesfully adopted by a number of CPAN authors.
>
> =cut
>
>

-- 
Jay Kuri
President
Ionzero LLC
P: 720-438-4660 x101