Commit Rules: Pushing To The NetBeans Mercurial Repository
Having push access to the NetBeans Mercurial repository is a privilege but also a responsibility: responsibility to the quality of the code and responsibility to other people working on NetBeans. In order to ensure that the quality of the code base is high and that you will not disturb anybody else's work, here are a few guidelines that will help you to validate your changesets before you push them into the NetBeans Mercurial repository.
1. Do Clean and Build
- When your modifications are ready to be pushed do a clean build to make sure that it does not negatively influence other modules. Invoke
- to build the artifacts (classfiles, etc.)
- to compile the NetBeans IDE.
2. Run commit validation test suite
- Execute commit validation test suite which is designed to test the basic functionality of NetBeans and shall affirm you that your integration is not completely broken. Execute
- Of course no test shall fail otherwise there is something wrong - probably with your integration. At the end it is printed out summary information about pass ratio of the suite. There is also provided a link to HTML presentation of the results. If something fails, you should follow this link and check error messages to determine what is wrong with your build.
3. Run tests from changed module(s)
- Execute unit tests that might be influenced by your changes. For example when committing into the form module its test shall be run by
ant -f form/build.xml test
- and shall not fail.
4. Ready for integration
- If the IDE compiles, tests pass you are ready for integration. Check what you have changed by evaluating the output of
hg out -p
- and if the output really contains what you have modified do
Tips and tricks
- If you participate in development, you should be subscribed to firstname.lastname@example.org. Failures in daily builds as well as continuous builds are announced there and if your integration breaks something, you can react quickly. If you are going to fix such a problem please reply to the broken_build message, so others know that it is being solved.
- Usually you commit changes that have an entry in the Bugzilla tracker (bug, task, enhancement). In this case mention the issue number in the commit message. For example you write
hg ci -m '#31043: Fixing the screen resolution'
- and include the changeset hash of the commit in the description field when resolving the issue. Then it is possible to find out more about the commit in the Bugzilla and it is possible to find the sources that were modified to resolve the issue.
- Do not check in debug code that depends on a modified API with something made public that isn't. Solution: Always do a sanity diff.
- Do not check in a class that also contains a change that's part of a different bug fix. Solution: Always do a sanity diff