Committing to Danga Projects

Rules

People with commit access are asked to respect the following rules/guidelines:

• Licensing: you agree to license your contributions under the same terms as the project you're committing to.
• Attribution: don't use code from other projects with incompatible licenses. When it is compatible, give attribution to the source.
• Tests:
  • Add new tests -- and a lot of small tests are preferred over huge, monolithic ones
  • Don't break tests -- run the test suite before you commit. If it doesn't pass, don't commit.
• Docs:
  • Update docs -- if there are existing docs, you must append/update them
  • Add new docs -- if there aren't existing docs, you aren't expected to write docs for everything, but it'd be appreciated. :) in any case, new methods/functions should be documented clearly in code above the function with expected arguments, return values, whether they throw exceptions, etc. Then somebody writing docs in the future know what your assumptions were.
• Trunk vs branches -- trunk should be stable and usable. If you need to do crazy/experimental stuff, do it in a branch. You also won't get yelled at for committing crazy stuff if you work in a branch. :)
• Major/questionable/policy/semantic changes -- discuss on mailing list first. Get review/approval to commit to trunk.
• Tiny/obvious stuff, docs, new tests -- just commit without asking
• Commit granularity -- one commit per logical change! Two dozen small, discrete commits are preferred over one huge mess of a commit. And please have good commit messages. Whitspace cleanups, refactoring, etc should all be in separate commits, never along with functional changes.
• Double-check yourself -- always look at "svn diff" before committing, reviewing and making sure diff is as minimal and readable as possible, and that no debugging stuff slips in.
• Update ChangeLog -- if there's a CHANGES or ChangeLog file, update it.
• Style -- follow the style of code around you! We're not religious about one style over another. We are religious about having a consistent style throughout a codebase. While local style takes precendence over explicit rules, some general guidelines are:
  • Whitespace -- no tabs, ever. 4 spaces. If a file doesn't have emacs/vim hints to make your editor do the right thing automatically, feel free to add them.
• Fix your bugs -- if you commit and somebody reports a bug/regression, you're expected to fix it. If you regularly crap on the tree and don't clean it up, you'll quickly find your patches reverted and commit access revoked. Just play nice.

Getting Commit Access

Generally you're invited by somebody to become a committer once you've submitted some patches to the mailing list.

When you're sent to this page, send your preferred username and an htdigest line for that username (realm "Danga") to brad@danga.com. Your email should include a statement that you've read and agreed to the above rules/guidelines, and that you agree to license your contributions under the same terms as the project you're contributing to.

Once you have commit access, please add yourself to the who.bml page (which will auto-update the live who.bml page).