CONTRIBUTE

If you like to become part of the community and submit patches, here's how
to do so for libccli.

You can submit issues and pull requests on github:

  https://github.com/rostedt/libccli

But note, I will convert any pull request into a patch and submit it via
the old fashion "git am" way.

You can email me patches to rostedt@goodmis.org. Please follow the
Linux kernel process when doing so:

   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst

Start by cloning the repository:

  git clone https://github.com/rostedt/libccli.git

Make your changes. When you are satisfied with them, commit them into git.
Here's some helpful hints for your git commits.

1) When making changes, please follow the coding style defined by the file
   called CODING_STYLE in this directory.

2) Every commit should only do one thing.
   That is, if your work requires some cleaning up of code, do that
   clean up as a separate commit and not with your functional changes.
   Find ways to take "steps" in modifying code. If you can break up
   your changes in a series of steps, do so.

3) The commit log should start with a title. Like the below

      ccli: Add CONTRIBUTE file

   Even though this repo is for libccli, start the topic with "ccli:" because
   I maintain several repositories, and when I'm looking at commit of one of
   them, I like to know which one it is for.

   Also start the rest of the line with a capital letter like a sentence, but
   do not include a period.

      ccli: Fix reading the prompt backwards

   instead of:

      ccli: fix reading the prompt backwards

   It just makes it nicer to read.

   The subject should say "what" is being done, whereas the body should be
   the "why".

4) The body of the commit (with a blank line from the title), should be self
   contained, and explain why you are making the change. The title should hold
   the "what" is changing, but the body contains the rationale for the change.
   It should be a stand alone, and not state things like "See the next patch",
   because when it is in git history, there's no knowing what the next patch
   is.  You can make statements like "This is needed for a <future-feature>
   that will come later". Where "<future-feature>" is something that you are
   working on and the current commit is one of the steps required to get there.

5) Add your Developer Certificate of Origin (DCO) at the bottom of the commit
   log. That is "Signed-off-by: Full Name <email>" where your full name is your
   real name (no pseudonyms). Optionally, if you are making the change on
   behalf of your company, you may also add your company name, if you are not
   using your company's email. "Signed-off-by: Full Name (Company) <email>".
   Please note, the DCO is your statement that you have the legal right to
   make these changes for the project you are submitting to.

You can use the Linux kernel "checkpatch.pl" script to help verify the formatting
of your patch:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl

Please note that checkpatch.pl is a guide and not a hard rule. If it reports a
fix that makes the code harder to read, that fix can probably be ignored.

  git format-patch --stdout HEAD~1..HEAD | ./checkpatch.pl

Finally, you can use the git "send-email" functionality:

  git send-email --from='<your-email> --to='rostedt@goodmis.org' HEAD~1..HEAD

If you are sending one patch, if you are adding more than one patch, also include
a cover letter:

  git send-email --cover-letter --annotate --from='<your-email> --to='rostedt@goodmis.org' <first-commit>~1..HEAD

If you receive feedback on your patches, and plan on sending another version,
please use the '-v' option to mark your patches that they are a new version.
For example, if you add "-v2" to the above commands, instead of having:
"[PATCH]" in the subject, it will have "[PATCH v2]", letting the reviewers know
that this is a new version. If you send another version, use "-v3" and so on.

For more information about git send-email:

  https://git-scm.com/docs/git-send-email