Development Team/Commit Guidelines
m   | 
		m   | 
		||
| (7 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
{{Header|1 = <h2>'''[[Development Team|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}  | {{Header|1 = <h2>'''[[Development Team|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}  | ||
| - | + | 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,   | + | * If you fix a bug, we ask that you also add a [http://en.wikipedia.org/wiki/Regression_testing 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 [http://redmine.darenet.org 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.  | * Don't commit unrelated changes together with a fix: do fine-grained commits.  | ||
| - | * Always check what you're committing  | + | * Always check what you're committing. Make sure you're only committing what you need. Do a <code>''hg diff''</code> of the files you're going to commit and check the changes.  | 
| + | * Make sure you don't change line endings and white space.  | ||
* Don't do reformatting commits, unless you're the original author of the code.  | * 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.  | 
| - | * Never commit code you didn't write yourself or   | + | |
* Follow the coding guidelines.  | * 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.  | 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 ==  | ||
| + | <pre>  | ||
| + | YYYY-MM-DD    Nickname/Name    <your@email.com>  | ||
| + | |||
| + |   * filename (function_name): meaingful explanation of change.  | ||
| + | |||
| + |   * repeat  | ||
| + | </pre>  | ||
Current revision as of 19:01, 28 July 2011
DareNET Development Wiki - Development Team/Commit Guidelines
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 
hg diffof the files you're going to commit and check the changes. - Make sure you don't change 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
