platform-releng/buildSchedule.html - www.eclipse.org/eclipse - Git at Google

 <!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=utf-8">
     <link rel="stylesheet" href="https://www.eclipse.org/default_style.css" type="text/css">
   </head>

   <body bgcolor="#FFFFFF" text="#000000">

     <h2 id="schedule">Eclipse Release Engineering build schedule</h2>
     <h4>Platform, JDT, PDE:
       <a href="http://download.eclipse.org/eclipse/downloads/">Downloads</a>,
       <a href="https://www.eclipse.org/eclipse/development/">Plans</a>;
       Equinox:
       <a href="http://download.eclipse.org/equinox/">Downloads</a>,
       <a href="https://projects.eclipse.org/projects/rt.equinox/next-release">Plans</a>.
       See also the <a href="https://wiki.eclipse.org/Simultaneous_Release">Simultaneous Release</a> plans.
     </h4>

     <font class="indexsub">Last change of static content: 2018-09-20.</font>

     <p>
     I-builds use branches specified in <a href="https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/streams/repositories_master.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.
     <br>&nbsp;&nbsp;&nbsp;(daily 18:00 <a href="https://en.wikipedia.org/wiki/Eastern_Time_Zone">Eastern Time</a>, EST/EDT, -0400/-0500)
     </p>

     <p>
     <a href="https://calendar.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL Calendar URL</a>
     </p>

     <iframe src="https://calendar.google.com/calendar/b/1/embed?mode=AGENDA&amp;height=600&amp;wkst=1&amp;bgcolor=%23FFFFFF&amp;src=prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com&amp;color=%23B1365F&amp;ctz=America%2FNew_York" style="border-width:0" width="800" height="600" frameborder="0" scrolling="no"></iframe>
     <h4 id="rebuilds">Rebuild Policy</h4>
     <ul>
       <li>Mondays' integration builds - rebuild if compile errors, missing plug-ins, the build is unusable, or if the drops do not get posted.</li>
       <li>Other integration builds - rebuild on request for serious or urgent issues.</li>
     </ul>

     <br>

     <h4 id="retention">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>The last four integration builds are retained in the I-build repository.</li>
       <li>Mondays' integration builds are retained until the release is available.</li>
       <li>Stable builds are retained until a release is available.</li>
     </ul>

     <br>

     <h4 id="notes">Build Notes</h4>

     <strong>For the 4.<i>&lt;n&gt;</i> Mondays' integration builds: </strong>
     <ul>
       <li>Build time is 18:00 (Eastern time).</li>
       <li>In the event of an integration build failure due to compile errors, missing plug-ins, or if the drops are not posted,<br>there will be a same day rebuild upon
       submission of a fix.</li>
       <li> In the event of multiple integration build failures due to problems in the submission (i.e. not infrastructure problems),
         <br>all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild.</li>
     </ul>

     <br>


     <p>In the above descriptions, a build is considered to be a failure if there are &quot;Red X&quot;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>: Committers are expected to run tests before pushing changes to master or a maintenance branch.
     In addition, teams should track test failures to detect
     integration problems early on. What we want to achieve is for the Monday
     4.<i>&lt;n&gt;</i> I-build to typically be successful, with an infrequent requirement for a rebuild.
     Failing builds until Wednesday 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>

     <h4 id="milestones">Milestone Weeks</h4>
     Here's the usual schedule for milestone weeks:
     <ul>
       <li>Monday: Last day of development (and even then, no "big changes"). After Monday 20:00 ET, no feature work or unrelated fixes are allowed -- only regression fixes.</li>
       <li>Tuesday: All-day test pass. Nobody should develop or fix anything. Literally spend the entire day testing.</li>
       <li>Wednesday: Fix day with a focus on fixing regressions found during the test day (Tuesday). No unrelated fixes. Review and thoroughly test all commits.
         <ul>
           <li>The last Wednesday build is the release candidate every team signs off on Thursday.</li>
           <li>The "New and Noteworthy" entries are due on Wednesday evening:<br>
               Git repo: <code>ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git</code><br>
               Gerrit: <code>ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git</code><br>
               Live website: <a href="https://www.eclipse.org/eclipse/news/4.10/">https://www.eclipse.org/eclipse/news/4.10/</a></li>
         </ul>
       </li>
       <li>Thursday: Sign-off after re-testing, or at least confirming no changes have been made to your component's code since the last time the component was tested well.</li>
       <li>Friday: Build is officially declared and made available.
         <ul>
           <li>The master branch stays closed until the milestone is officially released. (That is, it is not enough that your component has signed off.)</li>
         </ul>
       </li>
     </ul>

   </body>
 </html>
	<!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=utf-8">
	<link rel="stylesheet" href="https://www.eclipse.org/default_style.css" type="text/css">
	</head>

	<body bgcolor="#FFFFFF" text="#000000">

	<h2 id="schedule">Eclipse Release Engineering build schedule</h2>
	<h4>Platform, JDT, PDE:
	<a href="http://download.eclipse.org/eclipse/downloads/">Downloads</a>,
	<a href="https://www.eclipse.org/eclipse/development/">Plans</a>;
	Equinox:
	<a href="http://download.eclipse.org/equinox/">Downloads</a>,
	<a href="https://projects.eclipse.org/projects/rt.equinox/next-release">Plans</a>.
	See also the <a href="https://wiki.eclipse.org/Simultaneous_Release">Simultaneous Release</a> plans.
	</h4>

	<font class="indexsub">Last change of static content: 2018-09-20.</font>

	<p>
	I-builds use branches specified in <a href="https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/streams/repositories_master.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.
	<br>   (daily 18:00 <a href="https://en.wikipedia.org/wiki/Eastern_Time_Zone">Eastern Time</a>, EST/EDT, -0400/-0500)
	</p>

	<p>
	<a href="https://calendar.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL Calendar URL</a>
	</p>

	<iframe src="https://calendar.google.com/calendar/b/1/embed?mode=AGENDA&height=600&wkst=1&bgcolor=%23FFFFFF&src=prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com&color=%23B1365F&ctz=America%2FNew_York" style="border-width:0" width="800" height="600" frameborder="0" scrolling="no"></iframe>
	<h4 id="rebuilds">Rebuild Policy</h4>
	<ul>
	<li>Mondays' integration builds - rebuild if compile errors, missing plug-ins, the build is unusable, or if the drops do not get posted.</li>
	<li>Other integration builds - rebuild on request for serious or urgent issues.</li>
	</ul>

	<br>

	<h4 id="retention">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>The last four integration builds are retained in the I-build repository.</li>
	<li>Mondays' integration builds are retained until the release is available.</li>
	<li>Stable builds are retained until a release is available.</li>
	</ul>

	<br>

	<h4 id="notes">Build Notes</h4>

	<strong>For the 4.<i><n></i> Mondays' integration builds: </strong>
	<ul>
	<li>Build time is 18:00 (Eastern time).</li>
	<li>In the event of an integration build failure due to compile errors, missing plug-ins, or if the drops are not posted,<br>there will be a same day rebuild upon
	submission of a fix.</li>
	<li> In the event of multiple integration build failures due to problems in the submission (i.e. not infrastructure problems),
	<br>all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild.</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>: Committers are expected to run tests before pushing changes to master or a maintenance branch.
	In addition, teams should track test failures to detect
	integration problems early on. What we want to achieve is for the Monday
	4.<i><n></i> I-build to typically be successful, with an infrequent requirement for a rebuild.
	Failing builds until Wednesday 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>

	<h4 id="milestones">Milestone Weeks</h4>
	Here's the usual schedule for milestone weeks:
	<ul>
	<li>Monday: Last day of development (and even then, no "big changes"). After Monday 20:00 ET, no feature work or unrelated fixes are allowed -- only regression fixes.</li>
	<li>Tuesday: All-day test pass. Nobody should develop or fix anything. Literally spend the entire day testing.</li>
	<li>Wednesday: Fix day with a focus on fixing regressions found during the test day (Tuesday). No unrelated fixes. Review and thoroughly test all commits.
	<ul>
	<li>The last Wednesday build is the release candidate every team signs off on Thursday.</li>
	<li>The "New and Noteworthy" entries are due on Wednesday evening:<br>
	Git repo: <code>ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git</code><br>
	Gerrit: <code>ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git</code><br>
	Live website: <a href="https://www.eclipse.org/eclipse/news/4.10/">https://www.eclipse.org/eclipse/news/4.10/</a></li>
	</ul>
	</li>
	<li>Thursday: Sign-off after re-testing, or at least confirming no changes have been made to your component's code since the last time the component was tested well.</li>
	<li>Friday: Build is officially declared and made available.
	<ul>
	<li>The master branch stays closed until the milestone is officially released. (That is, it is not enough that your component has signed off.)</li>
	</ul>
	</li>
	</ul>

	</body>
	</html>