...

• Make the necessary code or documentation changes
• add or update unit tests
• perhaps update batchtest
  

Documenting changes

• the xdocs/changes.xml file should be updated (except for trivial updates, e.g. correcting spelling in documentation)
  

Ant targets to run before committing

• ant package
• ant test
• what else ? (I do not knowant test-headless/test-headed (whichever was not run by the ant test)
  

Files to commit

• Changes to files in the docs directory should need not be committed , these immediately. These files are built from xdocs. (Is this correct?)
  • When
  • Only when release candidates are being made from the Subversion branch should the files in the docs directory must be committed. (Is this correct?) They can be committed earlier, but it saves on commits if they are batched up and done less frequently.
    

Committing to Subversion

• Add a sensible description of your changes when committing to Subversion (what is obvious now, may not be obvious in several months/year's time)
  • If you have fixed a Bugzilla entry, then include the Bugzilla number in the comment.
  • SVN log entries can be changed later if you find the original message was not clear enough.
    

Updating Bugzilla entry

• If you have fixed a Bugzilla entry, then set the status to ? ( I do not know what)fixed, and include the Subversion change number in the Bugzilla comment. If there is some possibility that the fix is not complete, set the status to NeedInfo and ask the bug originator to confirm that the fix has been successful.