[eclipse-dev] Eclipse integration builds described

[John_Wiegand@xxxxxxx]

A stable build is a build that is reliable enough for most users to be productive.  An integration build is
an attempt to create a stable build.   Before going into the precise steps of the integration build process, 
there are two points worth drawing special attention to:
1. Eclipse developers need to adopt the most recent integration builds as they are made.  Because
we are using Eclipse to develop Eclipse (self-hosting), we can provide continuous feedback about
the quality of Eclipse.  This is only effective if we are on the current builds.
2. The eclipse-dev mailing list is the forum for discussing issues that keep an integration build from
being declared a stable build.

Now to the details.  Here is a description of how the Eclipse integration build process works, step by step:

Each component submits their build contribution to the Release Engineering team for the integration 
build.  (A build contribution is simply a list of CVS project versions for each plugin in your component.)
An integration build takes place weekly at noon EST each Tuesday.  Each component has been 
using and testing their contribution before submitting it, so it is expected that the contribution will work.    
If your component will have a build contribution for Tuesday, please inform Release Engineering 
Monday evening.

Once the build is complete, the automated tests will be run.
In addition, a very quick (5-10 minute) informal sniff test will be done on each platform.

The builds will be posted to the download page on eclipse.org.
If there are compile errors, the automated tests fail, or the sniff tests fail, the build will status will be a 
"red X".  If the tests pass, the build status will be a "green check."

The notification that the build has completed is posted to the eclipse-dev mailing list.  This notification 
includes the following information:
        enumeration of all plugins with compile errors
        unit test results for all components with failed automated tests
        defect numbers for any problems discovered during the sniff testing

Each component will immediately begin self hosting on the integration build.  (In many cases, a single 
committer for the component will make the initial foray using the new build.  Once the committer is 
successful, the remainder of the component team moves forward to the new build.)

Feedback on the quality of the build is posted to eclipse-dev (as a reply to the build notification post).  
Any problems that keep the component from productively using the build are both logged to the bug 
database and posted.  We should focus our eclipse-dev discussion on serious problems in the build - 
those problems that keep you from successfully using Eclipse. Developers with known workarounds 
or other feedback will respond.

A component with a fix to a serious defect discussed in the mailing list may provide a contribution for 
a Thursday build.  If your component intends to make a build contribution, please inform
Release Engineering immediately - declaring which defects you will be addressing.  

Components without serious defects will not make contributions for the Thursday build.  Only fixes are 
submitted to the Thursday build - not new development.  A Thursday build  follows the same test, build, 
validate process as a Tuesday build. (The Thursday build will only occur if serious defects are
discovered in the Tuesday build.)

If an integration build is of sufficient quality, it is declared a stable build and reposted as a stable build.

Feedback on this process is welcome.