Contributing

Submitting Issues

• If your issue is that libsndfile is not able to or is incorrectly reading one of your files, please include the output of the sndfile-info program run against the file.
• If you are writing a program that uses libsndfile and you think there is a bug in libsndfile, reduce your program to the minimal example, make sure you compile it with warnings on (for GCC I would recommend at least -Wall -Wextra) and that your program is warning free, and that is is error free when run under Valgrind or compiled with AddressSanitizer.

Submitting Patches

• Patches should pass all existing tests

• Patches should pass all pre-commit hook tests.

• Patches should always be submitted via a either Github “pull request” or a via emailed patches created using “git format-patch”.

• Patches for new features should include tests and documentation.

• Commit messages should follow the “How to Write a Git Commit Message” guide:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

  Additional rule: the commit message may contain a prefix. The prefix must contain the name of the feature or source file related to the commit and must end with a colon followed by the message body.

  Examples of good commit messages:

  1. Fix typo
  2. Update CHANGELOG.md
  3. Add ACT file format support
  4. ogg_vorbis: Fix granule position when seeking Vorbis streams

  Examples of bad commit messages:

  1. Fixed bug (rule 5)
  2. update docs (rule 3)
  3. Add very cool feature. (rule 4)

• Patches to fix bugs should either pass all tests, or modify the tests in some sane way.

• When a new feature is added for a particular file format and that feature makes sense for other formats, then it should also be implemented for one or two of the other formats.