[libdist-zilla-plugin-test-podspelling-perl] 10/10: Dist-Zilla-Plugin-Test-PodSpelling-2.006009
Axel Beckert
abe at deuxchevaux.org
Mon May 25 10:06:07 UTC 2015
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 <ether at 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 <you at 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 <random at 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-PodSpelling at 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-PodSpelling at rt.cpan.org|mailto:bug-Dist-Zilla-Plugin-Test-PodSpelling at rt.cpan.org>).
+I am also usually active on irc, as 'ether' at C<irc.perl.org>.
+
+=head1 AUTHORS
+
+=over 4
+
+=item *
+
+Caleb Cushing <xenoterracide at gmail.com>
+
+=item *
+
+Marcel Gruenauer <hanekomu at 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 <ether at cpan.org>
+
+=item *
+
+Randy Stauner <rwstauner at cpan.org>
+
+=item *
+
+Graham Knop <haarg at haarg.org>
+
+=item *
+
+David Golden <dagolden at cpan.org>
+
+=item *
+
+Harley Pig <harleypig at gmail.com>
+
+=item *
+
+Alexandr Ciornii <alexchorny at gmail.com>
+
+=item *
+
+Breno G. de Oliveira <garu at 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
More information about the Pkg-perl-cvs-commits
mailing list