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 <et...@cpan.org>
Date:   Sun May 3 20:09:29 2015 -0700

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

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 5fdcabd..951b0e0 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,220 +1,100 @@
-Checklist
-
-(and a short version for the impatient):
-
-Branching:
-- 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
-
-Commits:
-- 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 
"changes".
-       - includes motivation for the change, and contrasts its implementation 
with
-         previous behaviour
-- if you want your work included in the main repository, add a "Signed-off-by:
-  Your Name <y...@example.com>" 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
-
-Patch:
-- 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.
+CONTRIBUTING
 
-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
+faster).
 
-(4) Sign your work
+The distribution is managed with Dist::Zilla 
(https://metacpan.org/release/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
+https://metacpan.org/release/Dist-Zilla-Plugin-Test-PodSpelling.
 
-        (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 
Dist::Zilla::Plugin::Test::PodSpelling
 
-        (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`
+or
+  $ 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 <ran...@developer.example.org>
+  $ cpan `dzil listdeps --author --missing`
+or
+  $ 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`
+or
+  $ 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 
Dist::Zilla::Plugin::Test::PodSpelling
 
-"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 http://dzil.org/.
 
-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:
+https://github.com/karenetheridge/Dist-Zilla-Plugin-Test-PodSpelling
+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.
+https://help.github.com/articles/creating-a-pull-request
 
-   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 
to
-   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:
+https://rt.cpan.org/Public/Dist/Display.html?Name=Dist-Zilla-Plugin-Test-PodSpelling
+or via bug-dist-zilla-plugin-test-podspell...@rt.cpan.org.
 
-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
+http://dzil.org/#mailing-list.
+There is also an irc channel available for users of this distribution, at
+irc://irc.perl.org/#distzilla.
 
-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
-master).
+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
 
-{{$NEXT}}
+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
+++ b/LICENSE
@@ -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.
+
+Preamble
+
+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. 
+
+Definitions
+
+    "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
+license.
+
+(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:
+THE PACKAGE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS
+IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. THE IMPLIED
+WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
+NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT PERMITTED BY YOUR LOCAL
+LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT HOLDER OR CONTRIBUTOR WILL
+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
+DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE, EVEN IF
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/README.pod b/README.pod
new file mode 100644
index 0000000..d611cee
--- /dev/null
+++ b/README.pod
@@ -0,0 +1,159 @@
+=pod
+
+=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]
+
+or:
+
+       [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.
+
+=head1 DESCRIPTION
+
+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.
+
+=head1 ATTRIBUTES
+
+=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
+L<Test::Spelling>.
+
+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__>
+section.
+
+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
+process.
+
+=for Pod::Coverage gather_files
+
+=for Pod::Coverage mvp_multivalue_args
+munge_files
+munge_file
+register_prereqs
+
+=head1 SUPPORT
+
+=for stopwords irc
+
+Bugs may be submitted through L<the RT bug 
tracker|https://rt.cpan.org/Public/Dist/Display.html?Name=Dist-Zilla-PluginTest-PodSpelling>
+(or 
L<bug-dist-zilla-plugin-test-podspell...@rt.cpan.org|mailto:bug-dist-zilla-plugin-test-podspell...@rt.cpan.org>).
+I am also usually active on irc, as 'ether' at C<irc.perl.org>.
+
+=head1 AUTHORS
+
+=over 4
+
+=item *
+
+Caleb Cushing <xenoterrac...@gmail.com>
+
+=item *
+
+Marcel Gruenauer <hanek...@gmail.com>
+
+=back
+
+=head1 COPYRIGHT AND LICENSE
+
+This software is Copyright (c) 2015 by Caleb Cushing.
+
+This is free software, licensed under:
+
+  The Artistic License 2.0 (GPL Compatible)
+
+=head1 CONTRIBUTORS
+
+=for stopwords Karen Etheridge Randy Stauner Graham Knop David Golden Harley 
Pig Alexandr Ciornii Breno G. de Oliveira
+
+=over 4
+
+=item *
+
+Karen Etheridge <et...@cpan.org>
+
+=item *
+
+Randy Stauner <rwstau...@cpan.org>
+
+=item *
+
+Graham Knop <ha...@haarg.org>
+
+=item *
+
+David Golden <dagol...@cpan.org>
+
+=item *
+
+Harley Pig <harley...@gmail.com>
+
+=item *
+
+Alexandr Ciornii <alexcho...@gmail.com>
+
+=item *
+
+Breno G. de Oliveira <g...@cpan.org>
+
+=back
+
+=cut

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-perl/packages/libdist-zilla-plugin-test-podspelling-perl.git

_______________________________________________
Pkg-perl-cvs-commits mailing list
Pkg-perl-cvs-commits@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-perl-cvs-commits

Reply via email to