Build submissions are done before every integration build and milestone build. Integration builds typically occur on Tuesday. Please see the Platform Release Engineering page for more information. We do our build submission for an 8 a.m. build, at 4 p.m. the previous day.

If you miss the cut-off for the official build submission, but it is still before the build has started, then you can do your own build submission to make sure your fix gets into the build.

A warning email should be sent to "platform-ui-dev@eclipse.org" (or all committers) at the beginning of the days on which an official build submission is to occur, or if you do your own build submission.

The Platform-UI team suggests that the Release Engineering (releng) tool be installed before doing a build submission. It reduces the chance of error.

1. Exit Eclipse (if running)
2. Download the releng tool.
3. Unzip the tool into your plugins directory.
4. Start Eclipse

1. Make sure that your workspace contains all of the plug-ins contained in our modules. This includes plat-ui, plat-ui-examples and plat-ui-tests. Make sure to include fragments that are not appropriate for your platform, as they may need to be versioned as well. Check out the project org.eclipse.releng from HEAD.
2. Get rid of all outgoing changes in your workspace.
3. Run all the test suites. The definitive list of test suites is given by inspecting the test.xml files in all our test plug-ins. At the time of writing, they are roughly: databinding tests, navigator tests, parts references tests, session tests, rcp tests, JFace tests, tabbed properties view tests, and the rather large UiTestSuite. There are launch configurations that you can find in the debug/run launch dialog when you load all the test projects. You can use these to run the tests, rather than creating new ones. Be careful not to disturb focus while the test are running. If you're leaving the machine running, you may wish to increase the time it takes for the screensaver to kick in.
4. Run the build notes script. On Windows XP, I would recommend installing cygwin. Check to make sure the list of bugs fixed makes sense. To run the build script, execute the following:
    cvs-comment.sh TYYYYMMDD-HHHH HEAD workspace-location > log.txt
   where TYYYYMMDD-HHHH is when the build is scheduled to start, HEAD is the stream to check, workspace location is the directory that contains the build workspace, and log.txt is the file to which the results will be written.
5. Update the org.eclipse.ui/buildnotes_workbench.html file with the results of the build scripts. Commit to CVS.
6. Select a project in the Package Explorer, right-click and select "Team > Release".
7. Use the default map project, and then select all the projects in the "ui.map" file.
8. If the release is small, it is a good idea to check the list of changes.
9. Supply the name of the release. Our convention is to use TYYYYMMDD-HHHH, where T is the type (e.g., I for an integration build), YYYY is the year, MM is the month, DD is the day and HHHH is the hour the build is scheduled to start. If the name is already in use, then use a letter suffix (i.e., a, b, c, etc.).
10. As the commit comment, enter the information from the build notes script.
11. Send an email to platform-ui-dev with the information from the build notes script.

To do a build submission using CVS, use the above steps above, but do the following instead of using the releng tool:

1. Tag all projects you have changed with the name of the release. Our convention is to use TYYYYMMDD-HHHH, where T is the type (e.g., I for an integration build), YYYY is the year, MM is the month, DD is the day and HHHH is the hour the build is scheduled to start. If the name is already in use, then use a letter suffix (i.e., a, b, c, etc.).
2. Checkout "org.eclipse.releng".
3. Open "maps/ui.map".
4. Change the version(s) of the project(s) you have tagged.
5. Save the map.
6. Commit your changes to the map to CVS.

In the event of a test failure, our team must respond to platform-releng-dev with one of two responses. We can say that we want a recovery build the following day. Alternatively, we can say that the test failure is not significant, and that the quality of the build should not be affected. (In either case, a bug should likely be entered into the bug database.)

A recovery build can also be requested if there is a problem affecting the usability of the build. This problem should make the build unusable for testing and development use.

For a recovery build, the map will need to be updated to include our fixes. This can either be everything on the head in CVS, or just the particular fixes we need. The former should only be done if no risky changes have gone onto the head since the last (i.e., the failed) build submission.