| <html> |
| <head> |
| <title>Eclipse 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"> |
| <table border=0 cellspacing=5 cellpadding=2 width="100%" > <tr> |
| <td width="72%" height="90" align=left> <font class=indextop> build schedule</font><br> |
| <font class=indexsub>last updated 23/03/2006 13:30</font></td> |
| <td width="28%"><img src="http://dev.eclipse.org/images/Idea.jpg" height=86 width=120></td></tr> |
| </table> |
| |
| <strong><font size=4>Please note - we are now in the 3.2 Endgame. See the <a href="http://www.eclipse.org/eclipse/platform-releng/3.2-endgame-buildschedule.html">3.2 Endgame build schedule.</a> for more details.</font></strong> |
| |
| <font class=indextop> </font><table border=0 cellspacing=5 cellpadding=2 width="100%" > |
| <tr> <td align=LEFT valign=TOP colspan="2" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"> |
| Regularly Scheduled Builds</font></b></td></tr> |
| |
| |
| |
| <p> <br> |
| |
| N builds replace tags specified in org.eclipse.releng map files with HEAD.<br> |
| I builds use tags org.eclipse.releng map files. |
| <br>M builds use tags in the R3_2_maintenance |
| branch of org.eclipse.releng. |
| <br>Teams must update map files in time for I and M build start times.<br> |
| Performance testing will only occur where indicated.</p> |
| <p>Times are all EDT (GMT -5)</p> |
| |
| <table width="100%" border="1"> |
| <tr> |
| <td width="9%"> </td> |
| <td width="34%"><h4>Build</h4></td> |
| <td width="11%"><h4>Date (Local)</h4></td> |
| <td width="12%"><h4>Date (UTC)</h4></td> |
| <td width="34%"><h4>Rebuild Policy</h4></td> |
| </tr> |
| <tr> |
| <td rowspan="2">Monday</td> |
| <td> 3.3 N build<br> |
| </td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| <tr> |
| <td>Performance testing on the previous weeks' declared 3.2 milestone when |
| applicable</td> |
| <td>12:00 </td> |
| <td>17:00 UTC</td> |
| <td>Rebuild until success</td> |
| </tr> |
| <tr> |
| <td colspan="5"> </td> |
| </tr> |
| <tr> |
| <td rowspan="2">Tuesday</td> |
| <td>3.3 N build</td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| <tr> |
| <td>3.3 I build with performance testing against 3.1 performance data..</td> |
| <td>08:00 </td> |
| <td>13:00 UTC</td> |
| <td>Same day rebuild if compile errors, missing plugins, the build is unusable |
| or if the drops do not get posted.Otherwise, a rebuild will occur Wednesday |
| 8:00 . </td> |
| </tr> |
| <tr> |
| <td colspan="5"> </td> |
| </tr> |
| <tr> |
| <td rowspan="3">Wednesday</td> |
| <td>3.3 N build</td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| <tr> |
| <td>3.2 I rebuild if requested</td> |
| <td>12:00 </td> |
| <td>17:00 UTC</td> |
| <td>Same day rebuild if compile errors, missing plugins, the build is unusable |
| or if the drops do not get posted.Otherwise, a rebuild will occur Thursday |
| 8:00. </td> |
| </tr> |
| |
| <tr> |
| <td colspan="5"> </td> |
| </tr> |
| <tr> |
| <td rowspan="3">Thursday</td> |
| <td>3.3 N build with performance tests</td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| <tr> |
| <td>3.3 I rebuild if requested</td> |
| <td>08:00</td> |
| <td>13:00 UTC</td> |
| <td>Rebuild until success</td> |
| </tr> |
| <tr> |
| <td>Performance re-testing on eclipse 3.1. Tests built from perf_31x |
| stream of org.eclipse.releng map files.</td> |
| <td>12:00 </td> |
| <td>17:00 </td> |
| <td>Rebuild until success</td> |
| </tr> |
| <tr> |
| <td colspan="5"> </td> |
| </tr> |
| <tr> |
| <td rowspan="2">Friday</td> |
| <td>3.3 N build</td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| |
| <tr> |
| <td colspan="5"> </td> |
| </tr> |
| <tr> |
| <td>Saturday</td> |
| <td>3.3 N build</td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| <tr> |
| <td colspan="5"> </td> |
| </tr> |
| <tr> |
| <td>Sunday</td> |
| <td>3.3 N build</td> |
| <td>00:10 </td> |
| <td>05:10 UTC</td> |
| <td>No rebuild.</td> |
| </tr> |
| </table> |
| <p> </p> |
| <tr> |
| <TABLE BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <TR> <TD ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><B><FONT FACE="Arial,Helvetica" COLOR="#FFFFFF">Additional |
| Upcoming Builds</FONT></B></TD></TR> <TR> <TD HEIGHT="19"></table> |
| |
| <p></p> |
| <table border=0 cellspacing=5 cellpadding=2 width="100%" > |
| <tr> <td align=LEFT valign=TOP colspan="2" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Build Retention |
| Policy</font></b></td></tr> <tr> <td height="19"> <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> |
| <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></li></table> |
| |
| <table border=0 cellspacing=5 cellpadding=2 width="100%" > |
| <tr> <td align=LEFT valign=TOP colspan="2" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Build |
| Notes </font></b></td></tr> <tr> <td height="19"> We have decided to make some |
| minor changes in our build story in order to better focus the responsibility for |
| getting good integration builds on the developers: <p>For the 3.3 integration |
| |
| builds: <br> |
| - build time is 8:00 am (Eastern time) on Tuesday mornings. <br> |
| - 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.<br> - Otherwise, there will be a rebuild at 8 am Wednesday morning |
| to accommodate fixes that have a workaround or do not impact the general usability of the build. <br>-Teams are expected to indicate on the platform-releng-dev mailing list if they intend to contribute to a rebuild. <br> - in the event of a double integration build failure, all other |
| work will stop until <br> guaranteed-to-be-successful build contributions are |
| prepared for a rebuild at 8:00 am Thursday morning. <br> - if the Thursday 8:00 |
| am (Eastern time) integration build fails we will rebuild until success<br> - |
| once a good integration build is achieved, it will be marked as such on the website. |
| <br> -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.</p> |
| <p>For the 3.2 maintenance builds: <br> |
| - build |
| time is noon Wednesday (Eastern time) <br> - because of the nature |
| of the fixes in this stream, these builds should not fail. <br> However, if a |
| rebuild is requested by one of the teams, it will take place as soon <br> as the |
| build contribution is available. <br> - once a good integration build is achieved, |
| it will be marked as such on the website. </p><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>IMPORTANT: This strategy _requires_ |
| 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 |
| 3.2 build to typically be successful, with an infrequent requirement for a |
| Wednesday |
| morning build. Failing the Wednesday morning 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></td></tr> </table><p> </p></TABLE> |
| </body> |
| </html> |
