Difference between revisions of "TM/3.5 Ramp down Plan"

Latest revision as of 16:48, 23 May 2013

Project Plan

Our project plan is located in our 3.5.0 release record.

This ramp-down plan explains the timing and planning of the last milestones and release candidates for Target Management 3.5. It is essentially identical to our 3.4 ramp-down plan except that API freeze has been moved to M7. TM 3.5 is a mature project and this was deemed to be low risk and was agreed to by all committers.

For reference, see the Kepler/Simultaneous Release Plan, in particular the Kepler/Simultaneous Release Plan#Milestones and Release Candidates.

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

Ramp down for Kepler

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.

M7

We plan to be both API and functionally complete for M7. After M7 there will be no more breaking API changes or unsolicited API change requests accepted. 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.

Release Candidates

Release candidates will be produced every week. After the first release candidate 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 PMC required review, since there is little chance of that breaking anything, though it is still expected to be complete by M7, 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.

TM 3.5 Dates

• May 10 - M7 produced

After M7, 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 24 - RC1 produced

After RC1, all checkins must be associated with a bugzilla item describing the change - even simple cleanups must be described and linked with the commit 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 31 - RC2 produced

After RC2, 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 7 - RC3 produced

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

• June 14 - RC4 produced

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

Ramp down for Kepler SR1 - tentatively September 27, 2013

We will use the master branch for Kepler SR1. At some point after SR1 we will fork a R3_5_maintenance branch for continued maintenance work leading to SR2.

Since we expect to see only bug fixes without functional change in the TM 3.5.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 on demand builds. Quality of these builds is expected to be the same or better than any milestone. This also means that checkins into the master 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.5.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.

• August 19, 2013 RC1

After RC1, there will be a 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 RC1 needs to be verified.

• September 2, 2013 RC2 produced

After RC2, 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.

• September 9, 2013 RC3 produced

After RC3, we do not really want to put any more bug fixes into 3.4.1 unless an emergency turns up. Now, besides the normal component team review, project leadership and 1 additional committer must also review and vote +1 after reviewing the bug for appropriateness and risk. Escalation with the Tools PMC is also recommended.

• September 16, 2013 final bits available

Release will be declared with Kepler on September 27, 2013

Ramp down for Kepler SR2 - tentatively February 28, 2014

After SR1 we will create the R3_5_maintenance branch. We do not plan any more work except critical bug fixes on this branch.

Every fix must be reviewed by project leadership if available, and 1 additional committer up until RC3. After RC3 2 committers will be required to approve a change. No changes will be accepted after RC4 unless required to fix aggregation build issues.

• February 17, 2014 final bits available (RC4)

Release will be declared with Kepler SR2 on February 28