Difference between revisions of "DSDP/DD/DD 1.1 RampDownPolicy"

From Eclipsepedia

< DSDP‎ | DD
Jump to: navigation, search
m (DD 1.0 Dates)
(DD 1.1 Dates)
 
Line 26: Line 26:
 
* Nov 14th, RC1 produced
 
* Nov 14th, RC1 produced
  
:After this date, 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.
+
:After this date, besides the fix author, at least 1 committer must 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.
  
 
* Nov 21st, RC2 produced
 
* Nov 21st, RC2 produced
  
:After this date, 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.
+
:After this date, besides the fix author, at least 2 committers must review and vote +1 on bugzilla for each change 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.
  
 
* Nov 28th, Final Release
 
* Nov 28th, Final Release

Latest revision as of 16:40, 20 November 2008

[edit] Ramp down for Ganymede

When talking about API Freeze, we always mean public API only. Provisional, experimental "internal" API, as well as incubating components i.e. the IP-XACT editor are exempt from API freeze or feature freeze, although we will strive for release quality of these components as well.

Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects.

For M3, we plan to be API complete, so there will not be any more breaking API changes or unsolicited API changes. If needed, making non-breaking API change requires an explicit approval of another committer in the regular peer review, while making a breaking API change requires a committer vote on the mailing list with at least two committers voting +1 and no -1s.

For M4, we plan to be functionally complete. We will accept API changes only if regressions are involved, or serious issues need to be addressed. Process for making API changes is the same as in M3. After M4, the remaining Release Candidates are (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).

After M4, 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 and PII files are exceptions to the normal required review, since there is little chance of that breaking anything, though it is still expected to be complete by M4, 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.

[edit] DD 1.1 Dates

    • Nov 7th, M4 (RC0) produced
    At this point, 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.
    • Nov 14th, RC1 produced
    After this date, besides the fix author, at least 1 committer must 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.
    • Nov 21st, RC2 produced
    After this date, besides the fix author, at least 2 committers must review and vote +1 on bugzilla for each change 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.
    • Nov 28th, Final Release
    Final Release to the update site.