Acme-String-Trim

 view release on metacpan or  search on metacpan

docs/SubmittingPatches.pod  view on Meta::CPAN

=pod

=head1 Checklist

(and a short version for the impatient):

=head2 Commits:

=over 4

=item * make commits of logical units

=item * check for unnecessary whitespace with "git diff --check" before committing

=item * do not check in commented out code or unneeded files

=item * the first line of the commit message should be a short description and
should skip the full stop

=item * the body should provide a meaningful commit message, which:

docs/SubmittingPatches.pod  view on Meta::CPAN

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.

=item * 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.

=back

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.

=head2 (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

docs/SubmittingPatches.pod  view on Meta::CPAN

respected origin that is done poorly or does incorrect things.

If you really really really really want to do a PGP signed
patch, format it as "multipart/signed", not a text/plain message
that starts with '-----BEGIN PGP SIGNED MESSAGE-----'.  That is
not a text/plain, it's something else.

Unless your patch is a very trivial and an obviously correct one,
first send it with "To:" set to the RT email (or mailing list), with "cc:"
listing people who are involved in the area you are touching (the output from
"git blame $path" and "git shortlog --no-merges $path" would help to
identify them), to solicit comments and reviews.  After the list
reached a consensus that it is a good idea to apply the patch, re-send
it with "To:" set to the maintainer and optionally "cc:" the list for
inclusion.  Do not forget to add trailers such as "Acked-by:",
"Reviewed-by:" and "Tested-by:" after your "Signed-off-by:" line as
necessary.

=head2 (4) Sign your work

To improve tracking of who did what, we've borrowed the

docs/SubmittingPatches.pod  view on Meta::CPAN

E<10>

=item 1. Send it to the bug tracker and cc people who may need to know about
the change.

E<10>
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.

=item 2. You get comments and suggestions for improvements.  You may even
get them in a "on top of your change" patch form.

E<10>

=item 3. Polish, refine, and re-send to the the people who spend their
time to improve your patch.  Go back to step (2).