| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title>Eclipse (Platform, JDT, PDE and Equinox) Release Engineering Build Schedule</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| |
| <body bgcolor="#FFFFFF" text="#000000"> |
| |
| |
| <h2>Eclipse Release Engineering build schedule</h2> |
| <h4>(Platform, JDT, PDE and Equinox)</h4> |
| <font class=indexsub>static content last updated 2013-05-17</font> |
| |
| |
| <p> |
| I-builds use branches specified in <a href="http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/streams/repositories.txt">repositories.txt</a> file, from |
| master branch of aggregator (eclipse.platform.releng.aggregator). The projects built are submodules of aggregator so normally |
| there is one line in repositories.txt file for each submodule of the aggregator. |
| </p> |
| <p> |
| N-builds always use 'master' branch of the repositories built. |
| </p> |
| <p> |
| M-builds use a branch of the aggregator (and therefore a branch of the repositories.txt file) |
| and, like I-builds, pull whatever branch is specified in the repositories.txt file. |
| </p> |
| <p> |
| <ul> |
| <li><a href="http://www.google.com/calendar/feeds/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic">XML</a></li> |
| <li><a href="http://www.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL</a></li> |
| </ul> |
| </p> |
| |
| <p> |
| <iframe src="http://www.google.com/calendar/embed?mode=AGENDA&height=600&wkst=1&bgcolor=%23FFFFFF&src=prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com&color=%237A367A" style="border-width:0" scrolling="auto" width="800" height="600" frameborder="0"></iframe> |
| </p> |
| |
| |
| <h4>Rebuild Policy</h4> |
| <ul> |
| <li>Nightly builds - No rebuilds</li> |
| <li>Integration builds - Same day rebuild if compile errors, missing plugins, the build is unusable or if the drops do not get posted.Otherwise, a rebuild the next day at 8:00am.</li> |
| <li>Maintenance builds - Rebuild until success</li> |
| </ul> |
| |
| <br> |
| |
| <h4>Build Retention Policy</h4> |
| |
| <p>In an effort to reduce our disk utilization on the eclipse.org infrastructure and reduce the amount of data sent to the mirrors, we have adopted the following build retention policy.</p> |
| <ul> |
| <li>Release builds are kept indefinitely and moved to the archive.eclipse.org server as appropriate</li> |
| <li>Four integration and nightly builds are retained</li> |
| <li>Maintenance builds are kept until a release of the maintenance stream is available.</li> |
| <li>Stable builds are retained until a release is available.</li> |
| </ul> |
| |
| |
| <br> |
| |
| <h4>Build Notes</h4> |
| |
| |
| <strong>For the 4.<i><n></i> Integration builds: </strong> |
| <ul> |
| <li>build time is 8:00 am (Eastern time) on Tuesday mornings.</li> |
| <li>In the event of an integration build failure due to compile errors, missing plugins or if the drops are not posted,<br>there will be a same day rebuild upon |
| submission of a fix.</li> |
| <li>Otherwise, there will be a rebuild at noon Wednesday morning to accommodate fixes that have a workaround or do not impact the general usability of the build. |
| <li>Teams are expected to indicate on the platform-releng-dev mailing list if they intend to contribute to a rebuild.</li> |
| <li> In the event of a double integration build failure, all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild at 8:00 am Thursday morning.</li> |
| <li> if the Thursday 8:00 am (Eastern time) integration build fails we will rebuild until success </li> |
| <li> once a good integration build is achieved, it will be marked as such on the website.</li> |
| <li> the Releng team will often request a go/no go status from all teams to determine if the build is suitable for the week's testing. If you provide status and then |
| recontribute to a subsequent build, you are required to revalidate the build and provide an updated status.</li> |
| </ul> |
| |
| <br> |
| |
| <strong>For the 4.<i><n-1></i>.x maintenance builds: </strong> |
| <ul> |
| <li>Build time is 8am Wednesday (Eastern time)</li> |
| <li>Due to the nature of the fixes in this stream, these builds should not fail. However, if a |
| rebuild is requested by one of the teams, it will take place as soon as the build contribution is available.</li> |
| </ul> |
| |
| |
| <br> |
| |
| <p>In the above descriptions, a build is considered to be a failure if there are "Red X"s that the developers |
| agree represent valid reasons for them to not begin using the integration build. |
| An example of a Red X which would *not* require a re-build would be a test which |
| failed because the test was bogus. </p> |
| |
| <p><strong>IMPORTANT</strong>: This strategy <strong>requires</strong> |
| us to have good build inputs. All teams must use the tools to pre-build and test |
| their submissions. In addition, teams should track the nightly builds to detect |
| integration problems early on. What we want to achieve is for the Tuesday morning |
| 4.<i><n></i> build to typically be successful, with an infrequent requirement for a |
| Wednesday |
| noon build. Failing the Wednesday noon rebuild should be treated as a catastrophic |
| failure. In other words, more than two or three of these per year is an unacceptable |
| |
| failure rate. </p> |
| </body> |
| </html> |
