Home Explore Help
Sign In
TorqueEngine
/
Torque3D-clone
2
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Branch: development
Branches Tags
Torque3D-clone
/
Engine
/
lib
/
libsndfile
/
CONTRIBUTING.md

CONTRIBUTING.md 2.1 KB
Permalink History 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.