Development Team/Commit Guidelines - Revision history

Admin at 19:01, 28 July 2011

2011-07-28T19:01:20Z

← Older revision		Revision as of 19:01, 28 July 2011
Line 9:		Line 9:
	* 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. 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.		* 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 ~~changing~~ line endings and white space.	+	* 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 copyright notices from the code.

Admin at 19:00, 28 July 2011

2011-07-28T19:00:59Z

← Older revision		Revision as of 19:00, 28 July 2011
Line 8:		Line 8:
	* Do a regression test run if making changes to core functionality before committing.		* 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. Make sure you're only committing what you need. Do a <code>''~~svn~~ diff''</code> of the files you're going to commit and check the changes.	+	* 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 changing line endings and white space.		* 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.		* Don't do reformatting commits, unless you're the original author of the code.

Admin: /* Upstream Merges/Sync */

2009-10-30T03:37:34Z

Upstream Merges/Sync

← Older revision		Revision as of 03:37, 30 October 2009
Line 26:		Line 26:
	* repeat		* repeat
	</pre>		</pre>
-
-	~~== 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~~

Admin at 03:37, 30 October 2009

2009-10-30T03:37:15Z

← Older revision		Revision as of 03:37, 30 October 2009
Line 13:		Line 13:
	* NEVER remove copyright notices from the code.		* NEVER remove copyright notices from the code.
	* NEVER remove licensing info 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.	+	* 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.		* Follow the coding guidelines.

Line 26:		Line 26:
	* repeat		* repeat
	</pre>		</pre>
		+
		+	== 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

Admin at 10:24, 2 October 2009

2009-10-02T10:24:38Z

← Older revision		Revision as of 10:24, 2 October 2009
Line 17:		Line 17:

	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>

Admin at 10:19, 2 October 2009

2009-10-02T10:19:13Z

← Older revision		Revision as of 10:19, 2 October 2009
Line 2:		Line 2:
	All developers should adhere to the following guidelines when making commits to any of DareNET's projects.		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.	+	* 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 [http://en.wikipedia.org/wiki/Regression_testing regression test] for it in the test suite.		* 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 ~~the~~ documentation, it may well be wrong. Test the behavior or ask ~~on the list for discussion if unsure~~. Don't be afraid of having your changes reviewed.	+	* 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.		* 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 ~~that~~ you're committing~~: make~~ sure you're only committing what you need ~~and make sure you don't change line endings and white space~~. Do a <code>''svn diff''</code> of the files you're going to commit and check the changes.	+	* Always check what you're committing. Make sure you're only committing what you need. Do a <code>''svn diff''</code> of the files you're going to commit and check the changes.
-	* Don't do reformatting commits, unless you're the original author of the code ~~or have obtained permission from the project maintainer~~.	+	* Make sure you don't changing line endings and white space.
-	* ~~Never~~ remove copyright notices from the code.	+	* Don't do reformatting commits, unless you're the original author of the code.
-	* ~~Never~~ remove licensing info from the code.	+	* NEVER remove copyright notices from the code.
-	* Never commit code you didn't write yourself or ~~code~~ that doesn't have a suitable license.	+	* NEVER remove licensing info from the code.
		+	* Never commit code you didn't write yourself or that doesn't have a suitable license.
	* 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.

Admin at 01:42, 9 June 2009

2009-06-09T01:42:55Z

← Older revision		Revision as of 01:42, 9 June 2009
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 ~~adhered~~ to the following guidelines when making commits to any of DareNET's projects.	+	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.		* ALWAYS add a ChangeLog entry with a meaningful explanation.

Admin at 09:55, 5 June 2009

2009-06-05T09:55:30Z

← Older revision		Revision as of 09:55, 5 June 2009
Line 1:		Line 1:
	{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}		{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}
-	~~Once you have commit access, there are a few other small rules~~ to ~~follow:~~	+	All developers should adhered to the following guidelines when making commits to any of DareNET's projects.

-	* ~~Always~~ add a ~~changelog~~ entry with a meaningful explanation.	+	* ALWAYS add a ChangeLog entry with a meaningful explanation.
-	* If you fix a bug, ~~please~~ add a [http://en.wikipedia.org/wiki/Regression_testing regression test] for it in the test suite.	+	* 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 the documentation, it may well be wrong. Test the behavior or ask on the list for discussion if unsure. Don't be afraid of having your changes reviewed.
		+	* 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: make sure you're only committing what you need and make sure you don't change line endings and ~~whitespace~~. Do a svn diff of the files you're going to commit and check the changes.	+	* Always check that you're committing: make sure you're only committing what you need and make sure you don't change line endings and white space. Do a <code>''svn diff''</code> of the files you're going to commit and check the changes.
-	* 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 or have obtained permission from the project maintainer.
-	* When fixing bugs, don't follow the documentation blindly, it may well be wrong. Test the behavior or ~~ask on~~ the ~~list for discussion if unsure. Don't be afraid of having your changes reviewed~~.	+
	* Never remove copyright notices from the code.		* Never remove copyright notices from the code.
-	* Never remove licensing info from code.	+	* Never remove licensing info from the code.
	* Never commit code you didn't write yourself or code that doesn't have a suitable license.		* Never commit code you didn't write yourself or code that doesn't have a suitable license.
	* Follow the coding guidelines.		* Follow the coding guidelines.
-	* Do a regression test run if making changes to core functionality before committing.

	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.

Admin at 02:03, 18 April 2009

2009-04-18T02:03:21Z

← Older revision		Revision as of 02:03, 18 April 2009
Line 1:		Line 1:
		+	{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}
	Once you have commit access, there are a few other small rules to follow:		Once you have commit access, there are a few other small rules to follow:

Admin at 13:56, 8 April 2009

2009-04-08T13:56:10Z

← Older revision		Revision as of 13:56, 8 April 2009
Line 2:		Line 2:

	* Always add a changelog entry with a meaningful explanation.		* Always add a changelog entry with a meaningful explanation.
-	* If you fix a bug, please add a regression test for it in the test suite.	+	* If you fix a bug, please add a [http://en.wikipedia.org/wiki/Regression_testing regression test] for it in the test suite.
	* 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: make sure you're only committing what you need and make sure you don't change line endings and whitespace. Do a svn diff of the files you're going to commit and check the changes.		* Always check what you're committing: make sure you're only committing what you need and make sure you don't change line endings and whitespace. Do a svn diff of the files you're going to commit and check the changes.