Platform UI/Development Process

Milestones, Triage, Commits, Builds, Map Files, Milestone Week

Eclipse has milestones roughly every six weeks – check the development plan for the exact dates. In every milestone, we have five weeks of development and one week of stabilization. See below for a detailed description of what goes on in the last week.

For bug triage, we take turns, with one team member doing triage for one milestone cycle. We try to keep our inbox clean and will assign bugs to their respective component area owners regularly.

There are a number of rules to follow when committing changes to CVS: First of all, make sure you do not cause compile errors for others on the team – everyone should be able to update from CVS at any time. Also, make sure you run the tests before releasing a change – others on the team are doing this as well and need to rely on the fact that any test failures can only be caused by their current outgoing changes and not an unrelated CVS update they did previously. Finally, every CVS commit needs a commit comment of the form "<what you did> - Bug <id> [<component area>] <description>". Everything after the dash can (and should) be copied from the bug title in bugzilla. When you mark the bug as resolved/fixed, add a comment that says to which development stream the change was committed, e.g. "Released to HEAD" or "Released to R_3_4_maintenance". It is usually a good idea to attach a patch with the fix to the bug so that it can be undone if necessary. Also, you should set the target milestone to the next milestone so that we can find all bugs we fixed during one milestone when we verify in the milestone week (see below).

Nightly builds run every night at 00:10 Eastern time. They use whatever is in HEAD at the time the nightly build runs. This means that it's not a good idea to check in changes around that time - the build process might end up with an inconsistent state if your change spanned more than one file.

Integration builds run every week, usually Tuesdays at 08:00 Eastern time. The integration builds do not take whatever is in HEAD at that time, teams need to submit a known good state to the build using the map files. They are in the project org.eclipse.releng, and each map file (one per component like UI, Debug, SWT, etc) contains basically the tag to use for the I build. If a team forgot to submit to the integration build, it would just use whatever was submitted last time.

We usually take turns, with one team member doing build submissions for one milestone cycle. Whoever does the build submission sends a heads-up mail to the platform-ui-dev mailing list. When they write, "leave HEAD in a good state around 4pm" this is because at about that time, they check out (or update) all the projects, runs the tests locally, and then do the build submission. "Doing the build submission" means tagging all the projects that have changed, and changing the map file to contain those tags. We use a tool for that (the "releng tools" from the download pages). It also generates the change log information at the same time. Normally, submitting to the integration builds is not a lot of work, except when something goes wrong and the tests are failing, or when it's milestone week.

The milestone week is special because we will produce quite a number of I-builds towards the milestone build, this starts on Monday and usually takes until Wednesday or Thursday, sometimes Friday until all teams are happy with the build as the milestone build. (This is when you see the GO or NO GO messages on platform-releng-dev.) During milestone week, we cannot release changes into HEAD unless it is a bug that would make it a NO GO. This is to stabilize the development, and to enable the person who is doing the build submissions to do so without having to create a branch during that week. Usually, there are a fair number of builds (with last-minute changes going in) on Monday. Tuesday is testing day - no development, just testing by all developers. We post a test plan on platform-ui-dev to coordinate who tests what. Part of testing day is going through all your bugs that were fixed within that milestone cycle, verifying that they are indeed fixed, and marking them as VERIFIED. (This is also the final state for bugs - we don't use the CLOSED state.) For verfication, we use one of the Monday builds that is designated as the test candidate build by the releng team. We don't start fixing on Tuesday - this happens on Wednesday, and only for critical bugs. For verifying tests, we usually check the build's test result page to see that the test was actually run during the build. It's a common mistake to write a test which then is not added to the suite. It's probably a good idea to try to run the snippets manually. For actual bugs with reproducible steps, you just try to reproduce it again. Sometimes, when revisiting bugs this way, you will notice that a variation on the steps to reproduce will still lead to an error. Lastly, if the bugfix was something like Javadoc clarification, or other things you cannot easily reproduce, we usually import the source from the build's plug-ins (not from CVS) to make sure the source changes are in the build.

There are special rules in effect after the API freeze, or during the endgame, or for work on maintenance releases.

Please check with one of the committers on IRC if you have any questions.