View source

From Eclipsepedia

for DSDP/TM/3.0 Ramp down Plan for Ganymede
You do not have permission to do that, for the following reason:
The action you have requested is limited to users in the group user.
You can view and copy the source of this page:
== Project Plan ==

This plan is about the detailed timing and planning of the last release candidates for DSDP Target Management 3.0 ([http://www.eclipse.org/dsdp/tm/development/plan.php TM 3.0 Project Plan]).

For reference, see the [[Ganymede Simultaneous Release]],
in particular the [[Ganymede Simultaneous Release#Milestones and Release Candidates]].

When talking about API Freeze, we always mean public API only. Provisional, experimental "internal"
API, as well as incubating components such as the Windows CE support or TCF are exempt from API 
freeze or feature freeze, although we will strive for release quality of these components as well.

== Ramp down for Ganymede == 

Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects. 
For milestones, the component lead (or delegate) is enough to review and approve a bug. 

'''For M6, we plan to be API complete''', so there will not be any more breaking API changes or unsolicited API change requests accepted.

'''For M7, we plan to be functionally complete'''. We will accept API changes only if regressions are involved, or serious issues need to be addressed. Only non-breaking API changes are accepted, and require review by the component lead and one additional committer. After M7, the remaining Release Candidates are (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).

'''After M7, production of release candidates starts'''. Additional RCs will be produced every week. After the first RC is produced, the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate: 
<ol>
* A regression
* A P1 or P2 bug, one that is blocking or critical, and some cases of major severities. 
* Documentation and PII files are exceptions to the normal PMC required review, since there is little chance of that breaking anything, though it is still expected to be complete by M6, and remaining work to be only documentation fixes (that is, no refactoring of plugins, build changes, etc, without PMC review and approval). 
* In addition to a bug meeting the above priority/severity conditions, there should be a simple, safe, well understood fix that is well isolated from effecting other components, that doesn't affect API or adopters, that has been well reviewed and well tested. 
* As each Release Candidate passes, the criteria for weighing the benefit-to-risk ratio criteria gets higher and higher, and as such requires a larger number of committers and PMC members to review.
</ol>
=== TM 3.0 Dates ===
<ol>
* May 6th, M7 produced

:After the 6th, API changes or functional enhancements should no longer happen. If there is a need for an API change or functional change, it requires a majority of committers to vote +1 on the mailing list or bugzilla bug. For plain bugfixes, review is optional although it is encouraged for any bug beyond real simple changes. Bug fixes that could potentially affect other components or adopters require project lead review. All checkins except simple [cleanup] should be associated with a corresponding bugzilla item.

* May 20th, RC1 produced

:After the 20th, all checkins must be associated with a bugzilla item describing the change - even simple cleanups must be described and linked with the checkin comment through a [123456] bug number. Besides the fix author, at least 1 additional committer must also review and vote +1 on bugzilla for each change, although the review may also happen after-the-fact to ensure smooth operation: fixes can be committed provided that the review and voting happens afterwards.

* May 27th, RC2 produced

:After May 27, at least 1 additional committer must review and approve each patch on bugzilla before it can be committed. Approvals after the fact can only happen in case of a must-fix-emergency where no reviewer is reachable in time.

* June 3rd, RC3 produced

:After June 3, at least 2 additional committers must agree in a vote after reviewing the bug for appropriateness and risk before it can be committed.

* June 10th, RC4 produced

:After June 10, all available committers must also review and agree in a vote after reviewing the bug for appropriateness and risk before it can be committed.

* June 17

:Final Release to Ganymede: following Server Freeze on June 24, public access on June 25
</ol>

== Ramp down for Ganymede SR1 (Sep 24, 2008) ==

Since we expect to see only bug fixes without functional change in the TM 3.0.1 Service Release, the testing and ramp down procedure is shortened compared to the full release. Because of that, we will also not have milestones for the Service Release, but produce weekly I-builds or M-builds every Thursday. Quality of these builds is expected to be the same or better than any milestone. This also means that checkins into the TM 3.0.1 maintenance branch typically need to be reviewed by at least one additional committer, unless the fix is very small and well understood or only affects documentation.

The last few weeks before the TM 3.0.1 release are reserved for testing and raising the bar for bug fixes, with appropriateness of a bug fix considered similar to the full release described above.

* Aug 26, 2008 RC0 (3.0.1 freeze and branching)

:After (Aug 26, 2008) we'll have an intensive [[TM 3.0.1 Testing]] pass. For futher fixes, besides the normal component team review, at least 1 additional committer '''should''' also review and vote +1 on bugzilla after reviewing the bug for appropriateness and risk. '''Every fix after RC0 needs to be verified.''' With RC0, we will '''fork off the R3_0_maintenance branch''' for further 3.0.1 work. Fixes after RC0 need to be applied to both the MAIN trunk and the R3_0_maintenance branch.

* Sep 3, 2008 RC1 produced

:After (Sep 3, 2008), besides the normal component team review, at least 1 additional committer '''must''' also review and vote +1 on bugzilla after reviewing the bug for appropriateness and risk. 

* Sep 10, 2008 RC2 produced

:After Sep 10, 2008, we do not really want to put any more bug fixes into 3.0.1 unless an emergency turns up. Now, besides the normal component team review, at least 1 PMC member and 1 additional committer must also review and vote +1 after reviewing the bug for appropriateness and risk.

* Sep 17, 2008 final bits available

:Release will be declared with Ganymede on Sep 24

== Ramp down for Ganymede SR2 (Feb 25, 2009) ==

We do not plan any more work except critical bug fixes on the maintenance branch.
For SR2 (TM 3.0.2), every fix must be made in both the R3_0_maintenance branch as well as HEAD.
Every fix must be reviewed by at least 1 PMC member and 1 additional committer.

* Feb 18, 2009 final bits available
:Release will be declared with Ganymede on Feb 25
Return to DSDP/TM/3.0 Ramp down Plan for Ganymede.
Retrieved from "http://wiki.eclipse.org/DSDP/TM/3.0_Ramp_down_Plan_for_Ganymede"