Â¥Ö÷

[·ÖÏí]Eclipse 3.3 Draft ÆÚ´ýeclipse 3.3µÄÕýʽ·¢²¼£¬ÒÔÏÂÊÇeclipse 3.3µÄ·¢²¼²Ý°¸¼Æ»® Eclipse 3.3 Draft Endgame Plan Updated frequently to reflect current status Status May 17, 2007 - We are building toward Eclipse 3.3RC1. Detailed Timeline May 2007   7 Mon 8:00 am EDT   Transition to fix and polish mode      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#Transition]details[/URL][/B]     17 Thu 00:10 am EDT   Release Candidate 1 build      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#FixPassAfterRC]rules[/URL][/B]     21 Mon 8:00 am EDT  Start 2-day test pass against RC1      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#TestPassBeforeRC2]details[/URL][/B]     23 Wed 8:00 am EDT   Start fix pass      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#FixPassAfterRC2]rules[/URL][/B]     25 Fri 00:10 am EDT   Release Candidate 2 build     [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#RC2]goals[/URL][/B]     28 Mon 8:00 am EDT   Start 2-day test pass against RC2      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#TestPassUsingRC2]details[/URL][/B]     30 Wed 8:00 am EDT   Start fix pass      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#FixPassAfterRC2]rules[/URL][/B]     June 2007   1 Fri 00:10 am EDT   Release Candidate 3 build      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#RC3]goals[/URL][/B]     4    Mon 8:00 am EDT   All-day test pass against RC3     [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#TestPassUsingRC3]details[/URL][/B]     5 Tue 8:00 am EDT   Start fix pass      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#FixPassAfterRC3]rules[/URL][/B]     8 Fri 00:10 EDT   Release Candidate 4 build     [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#RC4]goals[/URL][/B]          Post RC4 builds will be run to meet translation,            documentation and Europa goals.       June 2007        Release 3.3 available      [B][URL=http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html#Release3.3]details[/URL][/B]     Useful Links [URL=http://www.eclipse.org/eclipse/platform-releng/3.3-endgame-buildschedule.html]3.3 Endgame Build Schedule[/URL] - details on build times. [URL=http://wiki.eclipse.org/index.php/3.3_Release_checklist]Eclipse Release Checklist[/URL] - lists various things that need to be checked before each release. [URL=http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html]Eclipse Project 3.3 Plan[/URL] [URL=http://wiki.eclipse.org/index.php/Polish3.3]Eclipse 3.3 Polish Items[/URL] [URL=http://wiki.eclipse.org/index.php/Performance3.3]Eclipse 3.3 Performance Items[/URL] [URL=http://wiki.eclipse.org/index.php/Europa]Europa Simultaneous Release[/URL] What is the game plan? The Eclipse 3.3 release endgame involves a sequence of test/fix passes leading to the official 3.3 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 [URL=http://bugs.eclipse.org/bugs/]bugzilla bug reports[/URL] 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. 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. 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 [URL=mailto:platform-releng-dev@eclipse.org]platform-releng-dev@eclipse.org[/URL] 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. Release Candidate - Release candidate builds are like milestone builds. The main difference is that release candidate builds are usually immediately followed by a rigorous test pass, whereas milestone builds. 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. Test Pass - 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 [URL=http://dev.eclipse.org/bugs/]bugzilla[/URL]. Ideally, the bug report should explicitly call attention to regressions and potential "stop ship" problems. Fix Pass - 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.3 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 personally help fix any problems caused by changes made in fix passes. Details Transition to fix and polish Notes: All components transition on April 3 to polishing and fixing bugs for remainder of release cycle. PMC approval is required for feature work including API changes being done after M5. See the [URL=http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/maillist.html]eclipse pmc[/URL] mailing list. RC0/M7 Goals: RC0 and milestone M7 are one and the same All components feature complete. Accurate prioritization of all outstanding defects. String externalization complete (including mnemonics). 3.3 test plans posted. RC1 Goals: Accurate prioritization of all outstanding defects. All work on polish items complete. Final API. No outstanding P1 defects. As few P2 defects as possible. Note that May 8 is a holiday in France.   Test pass prior to RC2 Notes: 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.   RC2 Goals: Final artwork in place. Accurate prioritization of all outstanding defects. No outstanding P1 defects. As few P2 defects as possible. Note that Thursday May 17 is a holiday in Switzerland and France. Monday May 21 is a holiday in Canada. Monday May 28 is a holiday in the US and Switzerland.   Test pass using RC2 Notes: 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. RC3 Goals: Accurate prioritization of all outstanding defects. No outstanding P1 defects. As few P2 defects as possible. Test pass using RC3 Notes: 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. RC4 Goals: Accurate prioritization of all outstanding defects. Stable code base; no outstanding P1 defects. Release 3.3 Goal: Ship Eclipse 3.3 during the last week of June. Notes: 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.3 should be complete and available for download as soon as we are satisfied with it. Fix pass rules of engagement May 7-18 contributions to RC1 Focus: (1) P1 defects, (2) performance defects, (3) special "polish" items. Fixing other defects has lower priority. Fix approval: Another committer must +1 your bug report. All changes must have their associated bug reports tagged 3.3RC1. (Ongoing changes to component documentation do not require special approval.) API change approval: PMC must approve all API changes. No changes are to be released without prior approval and associated bug report. Notification requirements: None. Extra checking requirements: One additional committer must check all code changes prior to release.   May 21-May 25 contributions to RC2 Focus: (1) P1 defects, (2) performance defects, (3) special "polish" items. Fixing other defects has lower priority. Fix approval: Two committers must +1 your bug report. All changes must have their associated bug reports tagged 3.3RC2. (Ongoing changes to component documentation do not require special approval.) API change approval: PMC must approve all API changes. No changes are to be released without prior approval and associated bug report. Notification requirements: None. Extra checking requirements: Two additional committers must check all code changes prior to release.   May 28-June 1 contributions to RC3 Focus: Serious defects only; documentation. Fix approval: Two committers and a component lead must +1 your bug report. All changes must have their associated bug reports tagged 3.3RC3. (Ongoing changes to component documentation do not require special approval.) API change approval: PMC must approve all API changes. No changes are to be released without prior approval and associated bug report. Notification requirements: Announce bug numbers of intended non-doc changes to [URL=mailto:platform-releng-dev@eclipse.org]platform-releng-dev@eclipse.org[/URL] mailing list. Extra checking requirements: 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. June 4-June 8 contributions to RC4 Focus: Serious defects only; documentation. Fix approval: 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.3RC4 including risk assessment and prior approvals. (Ongoing changes to component documentation do not require special approval.) API change approval: PMC must approve all API changes. No changes are to be released without prior approval and associated bug report. Notification requirements: Announce bug numbers of intended non-doc changes to [URL=mailto:platform-releng-dev@eclipse.org]platform-releng-dev@eclipse.org[/URL] mailing list. Extra checking requirements: 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.    Êղؠ  ·ÖÏí   ¶¥(0)