Development Team/Commit Guidelines

Revision as of 03:37, 30 October 2009

All developers should adhere to the following guidelines when making commits to any of DareNET's projects.

• ALWAYS add a ChangeLog entry with a meaningful explanation. Please follow the format being currently used.
• If you fix a bug, we ask that you also add a regression test for it in the test suite.
• When fixing bugs, don't blindly follow documentation, it may well be wrong. Test the behavior or ask.
• Don't be afraid of having your changes reviewed. Routinely check the 'Code Reviews' page on the tracker.
• Do a regression test run if making changes to core functionality before committing.
• Don't commit unrelated changes together with a fix: do fine-grained commits.
• Always check what you're committing. Make sure you're only committing what you need. Do a svn diff of the files you're going to commit and check the changes.
• Make sure you don't changing line endings and white space.
• Don't do reformatting commits, unless you're the original author of the code.
• NEVER remove copyright notices from the code.
• NEVER remove licensing info from the code.
• Never commit code you didn't write yourself or that doesn't have a suitable license. Upstream merges/syncs should credit the actual author of the code.
• Follow the coding guidelines.

Also, remember to pat yourself on the back after the commit, smile and think we're a step closer to a better ircd/services.

Current ChangeLog Format

YYYY-MM-DD    Nickname/Name    <your@email.com>

  * filename (function_name): meaingful explanation of change.

  * repeat

Upstream Merges/Sync

This should be common sense, but please make sure you provide credit where it is due (e.g. credit the original authors of