RAP/Ramp down Ganymede

Ramp down for Ganymede

(based on DSDP/TM Ramp down plan)

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 M4, we plan to be API complete, so there will not be any more breaking API changes or unsolicited API change requests accepted.

For RC1, 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 RC1, the remaining Release Candidates are (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).

After RC1, additional RCs will be produced every week, devoted to fixing of severe bugs. The following describes the types of bugs that are appropriate for fixing:

• 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 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.

RAP 1.1 Dates

• May 6th, M4 produced

After the 6th, API changes or functional enhancements should no longer happen. If there is a need for an API 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.

• 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.

• 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, at least 2 additional committers and tech lead / project lead must 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