mirror of
https://gitee.com/openharmony/third_party_libsnd
synced 2024-11-23 09:59:54 +00:00
50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
# 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"](https://chris.beams.io/posts/git-commit/) 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.
|