1b815c7f3Sopenharmony_ci# Contributing 2b815c7f3Sopenharmony_ci 3b815c7f3Sopenharmony_ci## Submitting Issues 4b815c7f3Sopenharmony_ci 5b815c7f3Sopenharmony_ci* If your issue is that libsndfile is not able to or is incorrectly reading one 6b815c7f3Sopenharmony_ci of your files, please include the output of the `sndfile-info` program run 7b815c7f3Sopenharmony_ci against the file. 8b815c7f3Sopenharmony_ci* If you are writing a program that uses libsndfile and you think there is a bug 9b815c7f3Sopenharmony_ci in libsndfile, reduce your program to the minimal example, make sure you compile 10b815c7f3Sopenharmony_ci it with warnings on (for GCC I would recommend at least `-Wall -Wextra`) and that 11b815c7f3Sopenharmony_ci your program is warning free, and that is is error free when run under Valgrind 12b815c7f3Sopenharmony_ci or compiled with AddressSanitizer. 13b815c7f3Sopenharmony_ci 14b815c7f3Sopenharmony_ci## Submitting Patches 15b815c7f3Sopenharmony_ci 16b815c7f3Sopenharmony_ci* Patches should pass all existing tests 17b815c7f3Sopenharmony_ci* Patches should pass all pre-commit hook tests. 18b815c7f3Sopenharmony_ci* Patches should always be submitted via a either Github "pull request" or a 19b815c7f3Sopenharmony_ci via emailed patches created using "git format-patch". 20b815c7f3Sopenharmony_ci* Patches for new features should include tests and documentation. 21b815c7f3Sopenharmony_ci* Commit messages should follow the ["How to Write a Git Commit Message"](https://chris.beams.io/posts/git-commit/) guide: 22b815c7f3Sopenharmony_ci 1. Separate subject from body with a blank line 23b815c7f3Sopenharmony_ci 2. Limit the subject line to 50 characters 24b815c7f3Sopenharmony_ci 3. Capitalize the subject line 25b815c7f3Sopenharmony_ci 4. Do not end the subject line with a period 26b815c7f3Sopenharmony_ci 5. Use the imperative mood in the subject line 27b815c7f3Sopenharmony_ci 6. Wrap the body at 72 characters 28b815c7f3Sopenharmony_ci 7. Use the body to explain what and why vs. how 29b815c7f3Sopenharmony_ci 30b815c7f3Sopenharmony_ci Additional rule: the commit message may contain a prefix. The prefix must 31b815c7f3Sopenharmony_ci contain the name of the feature or source file related to the commit and must 32b815c7f3Sopenharmony_ci end with a colon followed by the message body. 33b815c7f3Sopenharmony_ci 34b815c7f3Sopenharmony_ci Examples of good commit messages: 35b815c7f3Sopenharmony_ci 1. Fix typo 36b815c7f3Sopenharmony_ci 2. Update CHANGELOG.md 37b815c7f3Sopenharmony_ci 3. Add ACT file format support 38b815c7f3Sopenharmony_ci 4. ogg_vorbis: Fix granule position when seeking Vorbis streams 39b815c7f3Sopenharmony_ci 40b815c7f3Sopenharmony_ci Examples of bad commit messages: 41b815c7f3Sopenharmony_ci 1. Fixed bug (rule 5) 42b815c7f3Sopenharmony_ci 2. update docs (rule 3) 43b815c7f3Sopenharmony_ci 3. Add very cool feature. (rule 4) 44b815c7f3Sopenharmony_ci 45b815c7f3Sopenharmony_ci* Patches to fix bugs should either pass all tests, or modify the tests in some 46b815c7f3Sopenharmony_ci sane way. 47b815c7f3Sopenharmony_ci* When a new feature is added for a particular file format and that feature 48b815c7f3Sopenharmony_ci makes sense for other formats, then it should also be implemented for one 49b815c7f3Sopenharmony_ci or two of the other formats. 50