Commit Rights

The procedure which will result in you having your OpenOffice.org account upgraded to 'DomainDeveloper' is currently a bit fuzzy. If you are an active participant in discussions on the mailing list governing the piece of OpenOffice.org which interests you, and you intend to contribute source code to the OpenOffice.org project, chances are that you will need CVS commit rights.

The biggest advantage to having such rights is, of course, the ability to contribute code yourself directly into the CVS repository, without having to attach patches to issues and badger another developer into incorporating your changes.

There are a number of steps required to receive CVS commit rights, and to then activate them so that they are useful to you.

Step 1. Sign a JCA (downloadable from http://www.openoffice.org/licenses/jca.pdf). Some of the reasons why you must do this are listed at http://www.openoffice.org/FAQs/faq-licensing.html#jca1.

Step 2. Do stuff which results in your account being upgraded to 'DomainDeveloper' status - submitting a couple of quality patches should do the trick.

Step 3. Follow the instructions here: http://www.openoffice.org/docs/ddSSHGuide.html on how to set up and create an SSH tunnel.

Step 4. Create a CWS (Child WorkSpace) for the area of work you intend to do. Directions on how to do this can be found here: http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxw. Note that without CVS commit rights, you cannot create CWSs. Also, if you have already got a specific milestone build, you can avoid the lengthly 'Update' process initiated by 'cwscreate' by using the -f option. This means, for example, if you are working on the OpenOffice 2.0.0 branch, you might already have the SRC680 m130 source. To avoid the CWS toolset updating you to a milestone you already have, you can enter 'cwscreate -f SRC680 m130 <cws name>'.

More details on creating CWSs can be found here: http://tools.openoffice.org/dev_docs/child_workspace_policies.html and here CWS.

Step 5. Go to the 'Environment Information System' at http://eis.services.openoffice.org/EIS2/servlet/Logon. Browse through the CWSs until you have found the CWS you just created. Once you've found it, click on the link at the top of the page, something like 'SRC680/<cws name>'. Fill in the relevant details and set yourself to be the owner of the CWS (enter your name into the textfield on the left of the dropdown combo box if you aren't already listed).

Step 6. Commit your code. Find someone on the relevant mailing list to QA your code, assign the issues to them (note that IssueZilla will reset their status to 'New' upon reassignment), then set the QA representative in EIS.

Step 7. As QA personnel generally don't have the expertise or time necessary to apply your changes and build a patched version of Office, it is necessary to supply them with a build containing your changes. Do a full build of Office, and upload the single download file from your instsetoo_native directory (for example: OOo_2.0_windows_install_en-US.exe) to: http://ooomisc.services.openoffice.org/pub/OpenOffice.org/cws/upload/. You can obtain details on how to upload files to this server from the project lead of of your project, or from one the release engineers.

Step 8. The QA person will test the bugs you have fixed on a standard milestone build, and on your patched version and confirm that the bugs are fixed and that no new bugs have been introduced. Once the QA process is finished, the QA person will merge your changes into the MWS, and you should see them in the next milestone build, and hopefully the next release.

Happy hacking!