This page is deprecated - see GIT_Rules instead
It would be nice if, before committing, you could build DS with your change on Fedora Core or RHEL and at least 1 other platform. This isn't always possible but it helps prevent cross-platform build breakage.
When checking in code
- List the bug number and summary for your fix, if multiple fixes, then identify each fix separately.
- If you change a piece of code in the server, you are responsible for making sure that the functionality works after your commits.
- Try to monitor the Tinderbox machines to be sure that your change didn't break the build. There is nothing worse than checking in a change at 5pm on Friday night and having the builds fail all weekend.
- When resolving the bug, update the bug report with the review request as above - bug(s) fixed and bug description can be omitted.
CVS Log Messages
- All bug fix log messages must have the bug number(s) in the log message.
- Always use the log message when using cvs commit. The bugzilla bug number should be included to make it easier to track down what was fixed.
- Short comments preferred - but not too short. Anything more than 5-10 lines may be get too long (depends on how complex your change is... but remember that commit comments are no substitute for source code comments). You can fit a lot of information in a few lines.
- This is an example of a good cvs checkin message:
Bug 110759 - log SLAPI_COMPONENT_NAME_NSPR for NSPR errors, map OS error to NSPR error in PR_SetError(), and fix some compiler warnings
- This is an example of a bad one. This is too short; a developer should not have to read the bug report or use cvs diff -r # -r # to find out in general terms what was fixed).
Bug fix for 700355
- And please, please, please do not include diffs in the commit comment (yes, it has been done before ... why? who knows?).
To create a patch file:
cvs diff -u5t > patch
Update the Bug
- Include the CVS output in the bug report. This provides a way to tie a specific version back to the code.