Related to #705.
2.1 KiB
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:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- 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:
- Fix typo
- Update CHANGELOG.md
- Add ACT file format support
- ogg_vorbis: Fix granule position when seeking Vorbis streams
Examples of bad commit messages:
- Fixed bug (rule 5)
- update docs (rule 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.