| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| |
| <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop' |
| |
| #***************************************************************************** |
| # |
| # index.php |
| # |
| # Author: |
| # Date: 2010-03-15 |
| # |
| # Description: Eclipse project Helios release freeze plan |
| # |
| # |
| #**************************************************************************** |
| |
| # |
| # Begin: page-specific settings. Change these. |
| $pageTitle = "Eclipse 3.6 endgame plan"; |
| $pageKeywords = "eclipse, 3.6, milestone, schedule, endgame, Helios"; |
| $pageAuthor = ""; |
| |
| # Add page-specific Nav bars here |
| # Format is Link text, link URL (can be http://www.someothersite.com/), target (_self, _blank), level (1, 2 or 3) |
| # $Nav->addNavSeparator("My Page Links", "downloads.php"); |
| # $Nav->addCustomNav("My Link", "mypage.php", "_self", 3); |
| # $Nav->addCustomNav("Google", "http://www.google.com/", "_blank", 3); |
| |
| # End: page-specific settings |
| # |
| |
| # Paste your HTML content between the markers! |
| ob_start(); |
| ?> |
| <style type="text/css"> |
| table.schedule tr.current td { |
| background-color: #F4EEFF; |
| } |
| </style> |
| <div id="midcolumn"> |
| <h1><?= $pageTitle ?></h1> |
| <div class="homeitem3col"> |
| <h3>Status</h3> |
| <p><b>June 7, 2010 - 3.6 development is complete</b></p> |
| </div> |
| <div class="homeitem3col"> |
| <h3>Detailed Timeline</h3> |
| <table class="schedule" border="0" cellspacing="0" cellpadding="0" align="center"> |
| <tr> |
| <td align="right" height="20"><b>May 2010</b> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">3</td> |
| <td align="right" height="20"> Mon 8:00 am EDT</td> |
| <td height="20"> <b>Transition to fix and polish mode</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#Transition"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">details</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">13</td> |
| <td align="right" height="20"> Thu 8:00 am EDT</td> |
| <td height="20"> <b>Release Candidate 1 build</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#FixPassAfterRC0"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">rules</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="30"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">17</td> |
| <td align="right" height="20"> Mon 8:00 am EDT</td> |
| <td height="20"> <b>Start 1-day test pass against RC1</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#TestPassBeforeRC2"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">details</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">18</td> |
| <td align="right" height="20"> Tue 8:00 am EDT</td> |
| <td height="20"> <b>Start fix pass</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#FixPassAfterRC1"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">rules</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="30"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">20</td> |
| <td align="right" height="20"> Thu 8:00 am EDT</td> |
| <td height="20"> <b>Release Candidate 2 build</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#RC2"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">goals</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="30"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">24</td> |
| <td align="right" height="20">Mon 8:00 am EDT</td> |
| <td height="20"> <b>Start 2-day test pass against RC2</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#TestPassUsingRC2"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">details</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">26</td> |
| <td align="right" height="20">Wed 8:00 am EDT</td> |
| <td height="20"> <b>Start fix pass</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#FixPassAfterRC2"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">rules</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="30"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">27</td> |
| <td align="right" height="20"> Thu 8:00 am EDT</td> |
| <td height="20"> <b>Release Candidate 3 build</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#RC3"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">goals</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">31</td> |
| <td align="right" height="20"> Mon 8:00 am EDT</td> |
| <td height="20"> <b>All-day test pass against RC3</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#TestPassUsingRC3"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">details</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td align="right" height="20"><b>June 2010</b> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">1</td> |
| <td align="right" height="20">Tue 8:00 am EDT</td> |
| <td height="20"> <b>Start fix pass</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#FixPassAfterRC3"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">rules</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20">3</td> |
| <td align="right" height="20"> Thu 8:00 am EDT</td> |
| <td height="20"> <b>Release Candidate 4 build</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#RC4"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">goals</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| <td align="right" height="20"></td> |
| <td align="right" height="20"></td> |
| <td height="20"><b>Post RC4 builds will only occur if required to meet translation, documentation and Helios goals. |
| <br>PMC approval is required for any changes including documentation.</b></td> |
| <td height="20"> </td> |
| <td height="20"> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| </tr> |
| <tr> |
| <td align="right" height="20"><b>June 2010</b> </td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| </tr> |
| <tr> |
| <td height="20"></td> |
| </tr> |
| <tr class="current"> |
| <td height="20"></td> |
| <td align="right" height="20">23</td> |
| <td align="right" height="20"></td> |
| <td height="20"> <b>Release 3.6 available</b></td> |
| <td height="20"> </td> |
| <td height="20"> <b><a href="#Release3.6"><img src="../images/jump_in_black.gif" border="0" hspace="3" width="12" height="10">details</a></b></td> |
| <td height="20"> </td> |
| </tr> |
| </table> |
| </div> |
| <div class="homeitem3col"> |
| <h3>Useful Links</h3> |
| <ul> |
| <li><a href="http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html ">Build Schedule</a> - details on build times.</li> |
| <li><a href="http://wiki.eclipse.org/index.php/3.3_Release_checklist">Eclipse Release Checklist</a> - |
| lists various things that need to be checked before each release.</li> |
| <li><a href="http://www.eclipse.org/projects/project-plan.php?projectid=eclipse">Eclipse Project Helios Plan</a></li> |
| <li><a href="http://wiki.eclipse.org/index.php/Helios">Helios Simultaneous Release</a></li> |
| </ul> |
| </div> |
| <div class="homeitem3col"> |
| <h3>What is the game plan?</h3> |
| <p>The Eclipse 3.6 release endgame involves a sequence of test/fix |
| passes leading to the official 3.6 release. Even more than at other |
| times, we welcome all the help we can get with testing and fixing the |
| various Eclipse release candidates. To participate effectively everyone |
| needs to track this schedule closely so that we end up testing the |
| latest release candidate and entering <a href="http://bugs.eclipse.org/bugs/">bugzilla |
| bug reports</a> in time to be considered for the fix pass that |
| immediately follows, giving rise to the next release candidate. |
| Throughout the process, we are most concerned with "stop ship" |
| (P1) bugs that must be fixed before we can declare that we have a |
| release. If we discover a "stop ship" bug late in the process, |
| we may have to slip the schedule to allow it to be fixed and retested. |
| This is why it is so important to ferret out "stop ship" bugs |
| as early as possible, while there is still time left in the schedule to |
| address them. Most of the bugs that will be uncovered will be less |
| serious. |
| </p> |
| <p> |
| During the fix passes, we prioritize the less serious bugs and |
| try to fix as many of the important ones as possible without |
| jeopardizing the schedule or the overall stability of the release. We're |
| always on the look out for "regression" type bugs where we |
| somehow manage to break something that had been working fine before. |
| Regressions are an important warning sign that our optimism and |
| enthusiasm is outpacing our understanding and abilities. Calling special |
| attention to regressions helps us to collectively bring our head back in |
| line with our feet, so to speak. With each cycle, we gradually raise the |
| bar on the kinds and numbers of changes that we will consider making, |
| until we reach a point where we would only fix "stop ship" |
| bugs and regressions. (The lesser bugs that we don't end up fixing will |
| be reconsidered for the next release.) Because of this progressive |
| tightening, the windows of opportunity for fixing problems within the |
| schedule are relatively narrow. Things works best if everyone pushes in |
| the right direction on the right things at the right times. |
| </p> |
| <p>As it is virtually impossible to work out all the details in advance, we will be |
| updating this page regularly to reflect current status and current |
| testing emphasis. If you are participating we suggest you bookmark this |
| page in your browser and check back frequently for updates. General |
| announcements during the endgame are posted to the <a href="mailto:platform-releng-dev@eclipse.org">platform-releng-dev@eclipse.org</a> |
| developer mailing list. Anyone participating in the endgame should be |
| subscribed to this list, and should direct any general questions and |
| comments about the process there as well.</p> |
| |
| <p><b><a name="ReleaseCandidate"></a>Release Candidate</b> |
| - Release candidate builds are like milestone builds. The main difference |
| is that release candidate builds are usually immediately followed by |
| a rigorous test pass. We test each release |
| candidate to find serious bugs and to increase our confidence in what |
| we have. We then fix the serious bugs in each release candidate to get |
| the next release candidate, which ought to be even better. Each release |
| candidate build is kicked off at the indicated time, with the goal being |
| to have a release candidate available within 24 hours. As the build |
| is ready, all of the teams validate it and declare it either "go" |
| of "no go" for testing. Getting a build that is testable may |
| require a few attempts. These happen in rapid succession, and we continue |
| rebuilding and revalidating until we have our next release candidate. |
| It is critical that we have enough time to do test passes. We will slide |
| the schedule and use weekends as necessary if there are delays of more |
| than 24 hours in getting a viable release candidate. Note that we will |
| also do warm-up builds in the days leading up to each release candidate |
| build to do early integration of fixes.</p> |
| |
| <p><b><a name="TestPass"></a>Test Pass</b> - Once we have a release |
| candidate build in hand, we enter an intensive test pass for a limited |
| period of time. Each component team is responsible for preparing a |
| comprehensive test plan for their component. These component test plans |
| cover all the functionality that requires manual testing, and identifies |
| the operating environments in which the testing needs to be done. Each |
| component team is responsible for staffing and carrying out their test |
| plan each cycle. Each component team is expected to have most of the |
| team testing throughout each test pass (a small subset of the team may |
| be focused on concurrently preparing candidate fixes for "stop |
| ship" bugs or other high priority tasks). Everyone in the Eclipse |
| community is encouraged to participate in test passes and report bugs to |
| <a href="https://bugs.eclipse.org/bugs/">bugzilla</a>. Ideally, the bug |
| report should explicitly call attention to regressions and potential |
| "stop ship" problems.</p> |
| |
| <p><b><a name="FixPass"></a>Fix Pass</b> - After each test pass, we analyze |
| and prioritize the set of outstanding bugs and enter an intensive fix |
| pass for a limited period of time where we try to fix the most pressing |
| problems. The bugs that we intend to fix for the next release candidate |
| are tagged accordingly (e.g., a bug tagged as Target 3.6 RC1 should |
| be fixed as of the release candidate 1 build). "stop ship" |
| bugs and regressions are always given first priority; less severe problems |
| are addressed by decreasing priority and as many as possible are fixed |
| in the time available. With each successive release candidate, we also |
| tighten the rules for the kinds of changes will be allowed to the code |
| base and increase the number of people that check the changes before |
| they are released. The rules apply to any and all changes to the code. |
| Any committer for any Eclipse component can perform the checking duties. |
| All committers for a component have the right to veto a change (with |
| an explanation) even after it has been released into the code base. |
| If such a veto occurs, the change automatically comes out until the |
| vetoing committer's concerns are addressed. The committer who releases |
| a given change, the person that checks the change, and the component |
| leads that approved making the change in the first place, are jointly |
| responsible for seeing it through. In other words, we expect a strong |
| commitment to <em>personally</em> help fix any problems caused by changes |
| made in fix passes.</p> |
| </div> |
| <div class="homeitem3col"> |
| <h3>Details</h3> |
| <h4><a name="Transition"></a>Transition to fix and polish</h4> |
| <ul> |
| <li>All components transition on May 3 to polishing and fixing |
| bugs for remainder of release cycle.</li> |
| <li>PMC approval is required for feature work including API changes |
| being done after M7. Use the <a href="http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/maillist.html">eclipse pmc</a> mailing list |
| to request API and feature work approval. |
| If a change is made to API to make it binary compatible with 3.5, technically this is |
| still an API change, and thus it should be treated in the same way as any other API change requests. |
| </li> |
| <li>No changes are to be released without appropriate approval and associated bug report. See the fix pass |
| <a href="#FixPassRules">rules of engagement</a> for specific approval requirements for each release candidate. |
| </li> |
| </ul> |
| <h4><a name="RC0"></a>RC0/M7 Goals</h4> |
| <ul> |
| <li>RC0 and milestone M7 are one and the same |
| <li>All components feature complete. |
| <li>Accurate prioritization of all outstanding defects.</li> |
| <li>String externalization complete (including mnemonics). |
| <li>3.6 test plans posted.</li> |
| </ul> |
| <h4><a name="RC1"></a>RC1 Goals</h4> |
| <ul> |
| <li>Accurate prioritization of all outstanding defects.</li> |
| <li>All work on polish items complete.</li> |
| <li>Final API.</li> |
| <li>No outstanding P1 defects. </li> |
| <li>As few P2 defects as possible.</li> |
| </ul> |
| <p>Monday May 3 is a holiday in Poland.<br/> |
| Thursday May 13 is a holiday in Switzerland, France, and Poland.</p> |
| <h4><a name="TestPassBeforeRC2"></a>Test pass prior to RC2</h4> |
| <p>Full day test pass involving entire community, using |
| the most recent nightly build to help stabilize HEAD for the upcoming RC2 build. |
| Committers with high priority fixes to make for RC2 can opt out of testing |
| to focus on getting in fixes. However, all committers should be working |
| with the test candidate build. |
| <h4><a name="RC2"></a>RC2 Goals</h4> |
| <ul> |
| <li>Final artwork in place. |
| <li>Accurate prioritization of all outstanding defects. |
| <li>No outstanding P1 defects. |
| <li>As few P2 defects as possible.</li> |
| </ul> |
| <p>Monday May 24 is a holiday in Canada, Switzerland, and France. <br/> |
| Monday May 31 is a holiday in the US.</p> |
| <h4><a name="TestPassUsingRC2"></a>Test pass using RC2</h4> |
| <p>Concerted 2-day testing effort on RC2 involving |
| entire community including all component teams. In an effort to |
| mix things up and hold off the onset of "tester |
| fatigue", each component team will be designating one team |
| member that will be assigned to test some other component.</p> |
| <h4><a name="RC3"></a>RC3 Goals</h4> |
| <ul> |
| <li>Accurate prioritization of all outstanding defects. |
| <li>No outstanding P1 defects. |
| <li>As few P2 defects as possible.</li> |
| </ul> |
| <h4><a name="TestPassUsingRC3"></a>Test pass using RC3</h4> |
| <p>Concerted 1-day testing effort on RC3 involving |
| entire community including all component teams, searching for |
| regressions and on the lookout for undiscovered "stop |
| ship" defects.</p> |
| <h4><a name="RC4"></a>RC4 Goals</h4> |
| <ul> |
| <li>Accurate prioritization of all outstanding defects. |
| <li>Stable code base; no outstanding P1 defects.</li> |
| </ul> |
| <h4><a name="R3.6"></a>Release 3.6</h4> |
| <p>Ship Eclipse 3.6 during the last week of June.</p> |
| <p>There is no formal test pass for RC4 and beyond other |
| than to check for last minute regressions. We will perform sanity |
| checking focused on documentation. Release 3.6 should be complete |
| and available for download as soon as we are satisfied with it.</p> |
| </div> |
| <div class="homeitem3col"> |
| <a name="FixPassRules"><h3>Fix pass rules of engagement</h3></a> |
| <a name="FixPassAfterRC0"></a><h4>May 3-13 - contributions to RC1</h4> |
| <p><b>Focus:</b>(1) P1 defects, (2) performance defects, (3) special |
| "polish" items. Fixing other defects has lower priority.</p> |
| <p><b>Fix approval:</b> Another committer must +1 your bug report. All changes |
| must have their associated bug reports tagged 3.6RC1. Ongoing changes |
| to component documentation do not require special approval. |
| <br> |
| No bugs must appear in <a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&classification=RT&target_milestone=3.6+RC1&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=review%2B&field0-1-0=keywords&type0-1-0=notsubstring&value0-1-0=documentation&field0-2-0=keywords&type0-2-0=notsubstring&value0-2-0=test&field0-3-0=keywords&type0-3-0=notsubstring&value0-3-0=example">this query</a>. |
| When your bug appears there, make sure that it gets a review+ or add the 'Documentation', 'example' or 'test' keyword if appropriate.</p> |
| <p><b>API change approval:</b> PMC must approve all API changes. No changes are to |
| be released without prior approval and associated bug report. |
| Send the request for approval to the <a href="http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/maillist.html">eclipse pmc</a> mailing list. |
| If a change is made to API to make it binary compatible with 3.5, technically this is still an API change, |
| and thus it should be treated in the same way as any other API change requests.</p> |
| <p><b>Notification requirements:</b> None.</p> |
| <p><b>Extra checking requirements:</b> One additional committer must check all code changes |
| prior to release.</p> |
| |
| <a name="FixPassAfterRC1"></a><h4>May 17-20 - contributions to RC2</h4> |
| <p><b>Focus:</b>(1) P1 defects, (2) performance defects, (3) special |
| "polish" items. Fixing other defects has lower priority.</p> |
| <p><b>Fix approval:</b> Two additional committers must +1 your bug report. All changes |
| must have their associated bug reports tagged 3.6RC2. (Ongoing changes |
| to component documentation do not require special approval.)</p> |
| <p><b>API change approval:</b> PMC must approve all API changes. No changes are to |
| be released without prior approval and associated bug report. |
| Send the request for approval to the <a href="http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/maillist.html">eclipse pmc</a> mailing list. |
| If a change is made to API to make it binary compatible with 3.5, technically this is still an API change, |
| and thus it should be treated in the same way as any other API change requests.</p> |
| <p><b>Notification requirements:</b> None.</p> |
| <p><b>Extra checking requirements:</b> Two additional committers must check all code changes |
| prior to release.</p> |
| |
| <a name="FixPassAfterRC2"></a><h4>May 24-27 - contributions to RC3</h4> |
| <p><b>Focus:</b> Serious defects only; documentation.</p> |
| <p><b>Fix approval:</b> Two additional committers and a component lead must +1 your bug report (3 people who are not the one making the change). All changes |
| must have their associated bug reports tagged 3.6RC3. (Ongoing changes |
| to component documentation do not require special approval.)</p> |
| <p><b>API change approval:</b> PMC must approve all API changes. No changes are to |
| be released without prior approval and associated bug report. |
| Send the request for approval to the <a href="http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/maillist.html">eclipse pmc</a> mailing list. |
| If a change is made to API to make it binary compatible with 3.5, technically this is still an API change, |
| and thus it should be treated in the same way as any other API change requests.</p> |
| <p><b>Notification requirements:</b> Announce bug numbers of intended non-doc changes to <a href="mailto:platform-releng-dev@eclipse.org">platform-releng-dev@eclipse.org</a> |
| mailing list.</p> |
| <p><b>Extra checking requirements:</b>Two additional committers must check all code changes |
| prior to release. Person who reported bug should mark the bug as |
| verified once they have retested.</p> |
| |
| <a name="FixPassAfterRC3"></a><h4>May 31 - June 3 - contributions to RC4</h4> |
| <p><b>Focus:</b>Serious defects only; documentation.</p> |
| <p><b>Fix approval:</b> Component lead plus one other component lead must |
| approve all work on a component. In addition, any component lead |
| can veto a change with cause. No changes are to be released without |
| associated bug report tagged 3.6RC4 including risk assessment and |
| prior approvals. (Ongoing changes to component documentation do |
| not require special approval.)</p> |
| <p><b>API change approval:</b> PMC must approve all API changes. No changes are to |
| be released without prior approval and associated bug report. |
| Send the request for approval to the <a href="http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/maillist.html">eclipse pmc</a> mailing list. |
| If a change is made to API to make it binary compatible with 3.5, technically this is still an API change, |
| and thus it should be treated in the same way as any other API change requests.</p> |
| <p><b>Notification requirements:</b>Announce bug numbers of intended non-doc changes to <a href="mailto:platform-releng-dev@eclipse.org">platform-releng-dev@eclipse.org</a> |
| mailing list.</p> |
| <p><b>Extra checking requirements:</b>Two additional committers must check all code |
| changes prior to release. Person who reported bug should mark the |
| bug as verified once they have retested.</p> |
| |
| </div> |
| </div> |
| |
| <?php |
| $html = ob_get_contents(); |
| ob_end_clean(); |
| |
| # Generate the web page |
| $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html); |
| ?> |
| |
