Skip to content

Latest commit

 

History

History
49 lines (41 loc) · 2.06 KB

CONTRIBUTING.md

File metadata and controls

49 lines (41 loc) · 2.06 KB
Raw

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.