Jump to: navigation, search

Difference between revisions of "DSDP/TML/RampdownPlan Galileo"

< DSDP‎ | TML
(TmL 0.2)
(TmL 0.2)
Line 7: Line 7:
  
 
== TmL 0.2 ==
 
== TmL 0.2 ==
 +
[http://wiki.eclipse.org/DSDP/TML/Ramp_down_policy_0.2 Ramp Down policy 0.2]
  
 
== TmL 0.3 ==
 
== TmL 0.3 ==

Revision as of 16:21, 30 January 2009

Ramp-Down Plans

TODO: Fabio Fantato

TmL 0.1

Ramp Down policy 0.1

TmL 0.2

Ramp Down policy 0.2

TmL 0.3

Ramp down for Eclipse 3.5

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:

         * A regression
         * A P1 or P2 bug, one that is blocking or critical, and some cases of major severities.
         * Documentation 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. 
 MTJ 1.0 Dates
         * May 1th, M7 produced 
         After May 1, 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 15th, RC1 produced 
         After the May 15, 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 22th, RC2 produced 
         After May 22, 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. 
         * May 29rd, RC3 produced 
         After Mat 29, at least 2 additional committers must agree in a vote after reviewing the bug for appropriateness and 
         risk before it can be committed. 
         * June 5th, RC4 produced 
         After June 5, 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 12th 
         Final Release to Eclipse 3.5: following Server Freeze on TBD, public access on TBD