This is an automated email from the git hooks/post-receive script.

abe pushed a commit to annotated tag v2.006009
in repository libdist-zilla-plugin-test-podspelling-perl.

commit ecfc55f03c300df1ac503e6b73b34124817091a7
Author: Karen Etheridge <>
Date:   Sun May 3 20:09:29 2015 -0700

            - first release under new management
            - minimum supported version lowered to 5.008
            - mark Dist::Zilla::Plugin::PodSpellingTests as deprecated in 
            - use the 'deprecated' warning category in [PodSpellingTests]
 CONTRIBUTING | 264 ++++++++++++++++-------------------------------------------
 Changes      |   4 +-
 LICENSE      | 207 ++++++++++++++++++++++++++++++++++++++++++++++
 README.pod   | 159 +++++++++++++++++++++++++++++++++++
 4 files changed, 440 insertions(+), 194 deletions(-)

index 5fdcabd..951b0e0 100644
@@ -1,220 +1,100 @@
-(and a short version for the impatient):
-- git checkout origin/master -b my-feature-or-bug
-  - ensure that you start on the right branch `build/master` is the "default"
-    branch, but patches should be based on `master`. It's generally safe to
-    patch against `build/master` so long as you don't attempt to modify
-    generated files or add files that exist in `master` that are intentionally
-    stripped from the build.
-- do not include more than one feature or bug in your branch
-- make sure that the test suite passes after your commit. This distribution
-  is built with Dist::Zilla ensure that running `dzil test` passes. You are
-  responsible for ensuring that generated, hand written and author tests pass.
-- make sure that you have tests for the bug you are fixing
-- make commits of logical units
-- check for unnecessary whitespace with "git diff --check" before committing
-- do not check in commented out code or unneeded files
-- the first line of the commit message should be a short description and
-  should skip the full stop
-- the body should provide a meaningful commit message, which:
-       - uses the imperative, present tense: "change", not "changed" or 
-       - includes motivation for the change, and contrasts its implementation 
-         previous behaviour
-- if you want your work included in the main repository, add a "Signed-off-by:
-  Your Name <>" line to the commit message (or just use the
-  option "-s" when committing) to confirm that you agree to the Developer's
-  Certificate of Origin
-- if you change, add, or remove any features or make some other user
-  interface change, the associated documentation should be updated as well.
-- if your name is not writable in ASCII, make sure that you send the
-  patch in the correct encoding.
-Long version:
-I started reading over the SubmittingPatches document for git,
-primarily because I wanted to have a document similar to it for
-my projects to make sure people understand what they are doing
-when they write "Signed-off-by" line.
-But the patch submission requirements are a lot more relaxed
-here on the technical/contents front, because my projects are
-thousand times smaller ;-).  So here is only the relevant bits.
-(0) Decide what to base your work on.
-In general, always base your work on the oldest branch that your
-change is relevant to.
-* A bugfix should be based on 'maint' in general. If the bug is not
-present in 'maint', base it on 'master'. For a bug that's not yet
-in 'master', find the topic that introduces the regression, and
-base your work on the tip of the topic. If a 'maint' branch is not present
-base it on master.
-* A new feature should be based on 'master' in general. If the new
-feature depends on a topic that is in 'pu', but not in 'master', base your
-work on the tip of that topic.
-* Corrections and enhancements to a topic not yet in 'master' should be
-based on the tip of that topic. If the topic has not been merged to 'next',
-it's alright to add a note to squash minor corrections into the series.
-* In the exceptional case that a new feature depends on several topics
-not in 'master', start working on 'next' or 'pu' privately and send out
-patches for discussion. Before the final merge, you may have to wait until
-some of the dependent topics graduate to 'master', and rebase your work.
-To find the tip of a topic branch, run "git log --first-parent
-master..pu" and look for the merge commit. The second parent of this
-commit is the tip of the topic branch.
-(1) Make separate commits for logically separate changes.
-Unless your patch is really trivial, you should not be sending
-out a patch that was generated between your working tree and
-your commit head.  Instead, always make a commit with complete
-commit message and generate a series of patches from your
-repository.  It is a good discipline.
-Describe the technical detail of the change(s).
-If your description starts to get too long, that's a sign that you
-probably need to split up your commit to finer grained pieces.
-That being said, patches which plainly describe the things that
-help reviewers check the patch, and future maintainers understand
-the code, are the most beautiful patches.  Descriptions that summarise
-the point in the subject well, and describe the motivation for the
-change, the approach taken by the change, and if relevant how this
-differs substantially from the prior version, can be found on Usenet
-archives back into the late 80's.  Consider it like good Netiquette,
-but for code.
-Oh, another thing.  I am picky about whitespaces.  Make sure your
-changes do not trigger errors with the sample pre-commit hook shipped
-in templates/hooks--pre-commit.  To help ensure this does not happen,
-run git diff --check on your changes before you commit.
-(2) Generate your patch using git tools out of your commits.
-git based diff tools (git, Cogito, and StGIT included) generate
-unidiff which is the preferred format.
-You do not have to be afraid to use -M option to "git diff" or
-"git format-patch", if your patch involves file renames.  The
-receiving end can handle them just fine.
+Thank you for considering contributing to this distribution.  This file
+contains instructions that will help you work with the source code.
-Please make sure your patch does not include any extra files
-which do not belong in a patch submission.  Make sure to review
-your patch after generating it, to ensure accuracy.  Before
-sending out, please make sure it cleanly applies to the "master"
-branch head.  If you are preparing a work based on "next" branch,
-that is fine, but please mark it as such.
+PLEASE NOTE that if you have any questions or difficulties, you can reach the
+maintainer(s) through the bug queue described later in this document
+(preferred), or by emailing the releaser directly. You are not required to
+follow any of the steps in this document to submit a patch or bug report;
+these are just recommendations, intended to help you (and help us help you
-(4) Sign your work
+The distribution is managed with Dist::Zilla 
+This means than many of the usual files you might expect are not in the
+repository, but are generated at release time (e.g. Makefile.PL).
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although this project is a lot
-smaller it is a good discipline to follow it.
+However, you can run tests directly using the 'prove' tool:
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as a open-source patch.  The rules are
-pretty simple: if you can certify the below:
+  $ prove -l
+  $ prove -lv t/some_test_file.t
+  $ prove -lvr t/
-        Developer's Certificate of Origin 1.1
+In most cases, 'prove' is entirely sufficent for you to test any
+patches you have.
-        By making a contribution to this project, I certify that:
+You may need to satisfy some dependencies.  The easiest way to satisfy
+dependencies is to install the last release -- this is available at
-        (a) The contribution was created in whole or in part by me and I
-            have the right to submit it under the open source license
-            indicated in the file; or
+If you use cpanminus, you can do it without downloading the tarball first:
-        (b) The contribution is based upon previous work that, to the best
-            of my knowledge, is covered under an appropriate open source
-            license and I have the right under that license to submit that
-            work with modifications, whether created in whole or in part
-            by me, under the same open source license (unless I am
-            permitted to submit under a different license), as indicated
-            in the file; or
+  $ cpanm --reinstall --installdeps --with-recommends 
-        (c) The contribution was provided directly to me by some other
-            person who certified (a), (b) or (c) and I have not modified
-            it.
+Dist::Zilla is a very powerful authoring tool, but requires a number of
+author-specific plugins.  If you would like to use it for contributing,
+install it from CPAN, then run one of the following commands, depending on
+your CPAN client:
-        (d) I understand and agree that this project and the contribution
-            are public and that a record of the contribution (including all
-            personal information I submit with it, including my sign-off) is
-            maintained indefinitely and may be redistributed consistent with
-            this project or the open source license(s) involved.
+  $ cpan `dzil authordeps --missing`
+  $ dzil authordeps --missing | cpanm
-then you just add a line saying
+You should then also install any additional requirements not needed by the
+dzil build but may be needed by tests or other development:
-       Signed-off-by: Random J Developer <>
+  $ cpan `dzil listdeps --author --missing`
+  $ dzil listdeps --author --missing | cpanm
-This line can be automatically added by git if you run the git-commit
-command with the -s option.
+Or, you can use the 'dzil stale' command to install all requirements at once:
-Notice that you can place your own Signed-off-by: line when
-forwarding somebody else's patch with the above rules for
-D-C-O.  Indeed you are encouraged to do so.
+  $ cpan Dist::Zilla::App::Command::stale
+  $ cpan `dzil stale --all`
+  $ cpanm Dist::Zilla::App::Command::stale
+  $ dzil stale --all | cpanm
-Also notice that a real name is used in the Signed-off-by: line. Please
-don't hide your real name.
+You can also do this via cpanm directly:
-Some people also put extra tags at the end.
+  $ cpanm --reinstall --installdeps --with-develop --with-recommends 
-"Acked-by:" says that the patch was reviewed by the person who
-is more familiar with the issues and the area the patch attempts
-to modify.  "Tested-by:" says the patch was tested by the person
-and found to have the desired effect.
+Once installed, here are some dzil commands you might try:
+  $ dzil build
+  $ dzil test
+  $ dzil test --release
+  $ dzil xtest
+  $ dzil listdeps --json
+  $ dzil build --notgz
-An ideal patch flow
+You can learn more about Dist::Zilla at
-Here is an ideal patch flow for this project the current maintainer
-suggests to the contributors:
+The code for this distribution is hosted at GitHub. The repository is:
+You can submit code changes by forking the repository, pushing your code
+changes to your clone, and then submitting a pull request. Detailed
+instructions for doing that is available here:
-0. You come up with an itch.  You code it up.
-1. Send it to the bug tracker and cc people who may need to know about
-   the change.
-   The people who may need to know are the ones whose
-   code you are butchering.  These people happen to be the ones who are most
-   likely to be knowledgeable enough to help you, but they have no obligation 
-   help you (i.e. you ask for help, don't demand).  "git log -p --
-   $area_you_are_modifying" would help you find out who they are.
+If you have found a bug, but do not have an accompanying patch to fix it, you
+can submit an issue report here:
+or via
-2. You get comments and suggestions for improvements.  You may even
-   get them in a "on top of your change" patch form.
+There is also a mailing list available for users of this distribution, at
+There is also an irc channel available for users of this distribution, at
-3. Polish, refine, and re-send to the the people who spend their
-   time to improve your patch.  Go back to step (2).
+If you send me a patch or pull request, your name and email address will be
+included in the documentation as a contributor (using the attribution on the
+commit or patch), unless you specifically request for it not to be.  If you
+wish to be listed under a different name or address, you should submit a pull
+request to the .mailmap file to contain the correct mapping.
-4. A topic branch is created with the patch and is merged to 'next',
-   and cooked further and eventually graduates to 'master'.
-In any time between the (2)-(3) cycle, the maintainer may pick it up
-from the list and queue it to 'pu', in order to make it easier for
-people play with it without having to pick up and apply the patch to
-their trees themselves.
-Know the status of your patch after submission
-* You can use Git itself to find out when your patch is merged in
-master. 'git pull --rebase' will automatically skip already-applied
-patches, and will let you know. This works only if you rebase on top
-of the branch in which your patch has been merged (i.e. it will not
-tell you if your patch is merged in pu if you rebase on top of
+This file was generated via Dist::Zilla::Plugin::GenerateFile::ShareDir 0.005 
from a
+template file originating in Dist-Zilla-PluginBundle-Author-ETHER-0.092.
diff --git a/Changes b/Changes
index 3754204..1e8f3ae 100644
--- a/Changes
+++ b/Changes
@@ -1,6 +1,6 @@
-Revision history for Perl extension {{$dist->name}}
+Revision history for Perl extension Dist-Zilla-Plugin-Test-PodSpelling
+2.006009  2015-05-04 03:08:46Z
         - first release under new management
         - minimum supported version lowered to 5.008
         - mark Dist::Zilla::Plugin::PodSpellingTests as deprecated in metadata
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..035e531
--- /dev/null
@@ -0,0 +1,207 @@
+This software is Copyright (c) 2015 by Caleb Cushing.
+This is free software, licensed under:
+  The Artistic License 2.0 (GPL Compatible)
+                      The Artistic License 2.0
+           Copyright (c) 2000-2006, The Perl Foundation.
+     Everyone is permitted to copy and distribute verbatim copies
+      of this license document, but changing it is not allowed.
+This license establishes the terms under which a given free software
+Package may be copied, modified, distributed, and/or redistributed.
+The intent is that the Copyright Holder maintains some artistic
+control over the development of that Package while still keeping the
+Package available as open source and free software.
+You are always permitted to make arrangements wholly outside of this
+license directly with the Copyright Holder of a given Package.  If the
+terms of this license do not permit the full use that you propose to
+make of the Package, you should contact the Copyright Holder and seek
+a different licensing arrangement. 
+    "Copyright Holder" means the individual(s) or organization(s)
+    named in the copyright notice for the entire Package.
+    "Contributor" means any party that has contributed code or other
+    material to the Package, in accordance with the Copyright Holder's
+    procedures.
+    "You" and "your" means any person who would like to copy,
+    distribute, or modify the Package.
+    "Package" means the collection of files distributed by the
+    Copyright Holder, and derivatives of that collection and/or of
+    those files. A given Package may consist of either the Standard
+    Version, or a Modified Version.
+    "Distribute" means providing a copy of the Package or making it
+    accessible to anyone else, or in the case of a company or
+    organization, to others outside of your company or organization.
+    "Distributor Fee" means any fee that you charge for Distributing
+    this Package or providing support for this Package to another
+    party.  It does not mean licensing fees.
+    "Standard Version" refers to the Package if it has not been
+    modified, or has been modified only in ways explicitly requested
+    by the Copyright Holder.
+    "Modified Version" means the Package, if it has been changed, and
+    such changes were not explicitly requested by the Copyright
+    Holder. 
+    "Original License" means this Artistic License as Distributed with
+    the Standard Version of the Package, in its current version or as
+    it may be modified by The Perl Foundation in the future.
+    "Source" form means the source code, documentation source, and
+    configuration files for the Package.
+    "Compiled" form means the compiled bytecode, object code, binary,
+    or any other form resulting from mechanical transformation or
+    translation of the Source form.
+Permission for Use and Modification Without Distribution
+(1)  You are permitted to use the Standard Version and create and use
+Modified Versions for any purpose without restriction, provided that
+you do not Distribute the Modified Version.
+Permissions for Redistribution of the Standard Version
+(2)  You may Distribute verbatim copies of the Source form of the
+Standard Version of this Package in any medium without restriction,
+either gratis or for a Distributor Fee, provided that you duplicate
+all of the original copyright notices and associated disclaimers.  At
+your discretion, such verbatim copies may or may not include a
+Compiled form of the Package.
+(3)  You may apply any bug fixes, portability changes, and other
+modifications made available from the Copyright Holder.  The resulting
+Package will still be considered the Standard Version, and as such
+will be subject to the Original License.
+Distribution of Modified Versions of the Package as Source 
+(4)  You may Distribute your Modified Version as Source (either gratis
+or for a Distributor Fee, and with or without a Compiled form of the
+Modified Version) provided that you clearly document how it differs
+from the Standard Version, including, but not limited to, documenting
+any non-standard features, executables, or modules, and provided that
+you do at least ONE of the following:
+    (a)  make the Modified Version available to the Copyright Holder
+    of the Standard Version, under the Original License, so that the
+    Copyright Holder may include your modifications in the Standard
+    Version.
+    (b)  ensure that installation of your Modified Version does not
+    prevent the user installing or running the Standard Version. In
+    addition, the Modified Version must bear a name that is different
+    from the name of the Standard Version.
+    (c)  allow anyone who receives a copy of the Modified Version to
+    make the Source form of the Modified Version available to others
+    under
+       (i)  the Original License or
+       (ii)  a license that permits the licensee to freely copy,
+       modify and redistribute the Modified Version using the same
+       licensing terms that apply to the copy that the licensee
+       received, and requires that the Source form of the Modified
+       Version, and of any works derived from it, be made freely
+       available in that license fees are prohibited but Distributor
+       Fees are allowed.
+Distribution of Compiled Forms of the Standard Version 
+or Modified Versions without the Source
+(5)  You may Distribute Compiled forms of the Standard Version without
+the Source, provided that you include complete instructions on how to
+get the Source of the Standard Version.  Such instructions must be
+valid at the time of your distribution.  If these instructions, at any
+time while you are carrying out such distribution, become invalid, you
+must provide new instructions on demand or cease further distribution.
+If you provide valid instructions or cease distribution within thirty
+days after you become aware that the instructions are invalid, then
+you do not forfeit any of your rights under this license.
+(6)  You may Distribute a Modified Version in Compiled form without
+the Source, provided that you comply with Section 4 with respect to
+the Source of the Modified Version.
+Aggregating or Linking the Package 
+(7)  You may aggregate the Package (either the Standard Version or
+Modified Version) with other packages and Distribute the resulting
+aggregation provided that you do not charge a licensing fee for the
+Package.  Distributor Fees are permitted, and licensing fees for other
+components in the aggregation are permitted. The terms of this license
+apply to the use and Distribution of the Standard or Modified Versions
+as included in the aggregation.
+(8) You are permitted to link Modified and Standard Versions with
+other works, to embed the Package in a larger work of your own, or to
+build stand-alone binary or bytecode versions of applications that
+include the Package, and Distribute the result without restriction,
+provided the result does not expose a direct interface to the Package.
+Items That are Not Considered Part of a Modified Version 
+(9) Works (including, but not limited to, modules and scripts) that
+merely extend or make use of the Package, do not, by themselves, cause
+the Package to be a Modified Version.  In addition, such works are not
+considered parts of the Package itself, and are not subject to the
+terms of this license.
+General Provisions
+(10)  Any use, modification, and distribution of the Standard or
+Modified Versions is governed by this Artistic License. By using,
+modifying or distributing the Package, you accept this license. Do not
+use, modify, or distribute the Package, if you do not accept this
+(11)  If your Modified Version has been derived from a Modified
+Version made by someone other than you, you are nevertheless required
+to ensure that your Modified Version complies with the requirements of
+this license.
+(12)  This license does not grant you the right to use any trademark,
+service mark, tradename, or logo of the Copyright Holder.
+(13)  This license includes the non-exclusive, worldwide,
+free-of-charge patent license to make, have made, use, offer to sell,
+sell, import and otherwise transfer the Package with respect to any
+patent claims licensable by the Copyright Holder that are necessarily
+infringed by the Package. If you institute patent litigation
+(including a cross-claim or counterclaim) against any party alleging
+that the Package constitutes direct or contributory patent
+infringement, then this Artistic License to you shall terminate on the
+date that such litigation is filed.
+(14)  Disclaimer of Warranty:
diff --git a/README.pod b/README.pod
new file mode 100644
index 0000000..d611cee
--- /dev/null
+++ b/README.pod
@@ -0,0 +1,159 @@
+=encoding UTF-8
+=head1 NAME
+Dist::Zilla::Plugin::Test::PodSpelling - Author tests for POD spelling
+=head1 VERSION
+version 2.006009
+=head1 SYNOPSIS
+In C<dist.ini>:
+       [Test::PodSpelling]
+       [Test::PodSpelling]
+       directories = docs
+       wordlist = Pod::Wordlist
+       spell_cmd = aspell list
+       stopwords = CPAN
+       stopwords = github
+       stopwords = stopwords
+       stopwords = wordlist
+If you're using C<[ExtraTests]> it must come after C<[Test::PodSpelling]>,
+it's worth noting that this ships in the C<[@Basic]> bundle so you may have to
+remove it from that first.
+This is an extension of L<Dist::Zilla::Plugin::InlineFiles>, providing
+the following file:
+  xt/author/pod-spell.t - a standard Test::Spelling test
+L<Test::Spelling> will be added as a develop prerequisite.
+=head2 directories
+Additional directories you wish to search for POD spell checking purposes.
+C<bin> and C<lib> are set by default.
+=head2 wordlist
+The module name of a word list you wish to use that works with
+Defaults to L<Pod::Wordlist>.
+=head2 spell_cmd
+If C<spell_cmd> is set then C<set_spell_cmd( your_spell_command );> is
+added to the test file to allow for custom spell check programs.
+Defaults to nothing.
+=head2 stopwords
+If stopwords is set then C<add_stopwords( E<lt>DATAE<gt> )> is added
+to the test file and the words are added after the C<__DATA__>
+C<stopwords> can appear multiple times, one word per line.
+Normally no stopwords are added by default, but author names appearing in
+C<dist.ini> are automatically added as stopwords so you don't have to add them
+manually just because they might appear in the C<AUTHORS> section of the
+generated POD document. The same goes for contributors listed under the
+'x_contributors' field on your distributions META file.
+=head1 METHODS
+=head2 add_stopword
+Called to add stopwords to the stopwords array. It is used to determine if
+automagically detected words are valid and print out debug logging for the
+=for Pod::Coverage gather_files
+=for Pod::Coverage mvp_multivalue_args
+=head1 SUPPORT
+=for stopwords irc
+Bugs may be submitted through L<the RT bug 
+I am also usually active on irc, as 'ether' at C<>.
+=head1 AUTHORS
+=over 4
+=item *
+Caleb Cushing <>
+=item *
+Marcel Gruenauer <>
+This software is Copyright (c) 2015 by Caleb Cushing.
+This is free software, licensed under:
+  The Artistic License 2.0 (GPL Compatible)
+=for stopwords Karen Etheridge Randy Stauner Graham Knop David Golden Harley 
Pig Alexandr Ciornii Breno G. de Oliveira
+=over 4
+=item *
+Karen Etheridge <>
+=item *
+Randy Stauner <>
+=item *
+Graham Knop <>
+=item *
+David Golden <>
+=item *
+Harley Pig <>
+=item *
+Alexandr Ciornii <>
+=item *
+Breno G. de Oliveira <>

Alioth's /usr/local/bin/git-commit-notice on 

Pkg-perl-cvs-commits mailing list

Reply via email to