Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "TM 2.0 Ramp down Plan for Europa"

Line 65: Line 65:
 
* Sep 13th, RC3 produced
 
* Sep 13th, RC3 produced
  
:After Sep 13th, we do not really want to put any more bug fixes into 2.0.1 unless an emergency turns up. Time is reserved for our [[DSDP/TM/Face-to-face Meeting 19-Sep-2007]], and release preparations. After Sep 13th, 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.
+
:After Sep 13th, we do not really want to put any more bug fixes into 2.0.1 unless an emergency turns up. Time is reserved for our [[DSDP/TM/Face-to-face Meeting Toronto 17-Sep-2007]], and release preparations. After Sep 13th, 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.
  
 
== Ramp down for Europa SR2 (29-Feb-2007) ==
 
== Ramp down for Europa SR2 (29-Feb-2007) ==

Revision as of 15:49, 31 July 2007

For reference, see the Europa Simultaneous Release, in particular the Milestones and Release Candidates.

Ramp down for Europa

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

From M6 to M7/RC0 on May 18th, we expect each component lead (or delegate) to review and verify their teams' bugs.

After the first RC is produced, other RCs will be produced, if needed, 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 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.

TM 2.0 Dates

    • May 18th, M7/RC0 produced
    After the 18th, 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. Until RC1 this is optional.
    • May 25th, RC1 produced
    After the 25th, 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.
    • June 5th, RC2 produced
    After June 5, 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.
    • June 14th, RC3 produced
    After the 14th, besides the normal component team review, all available committers must also review and agree in a vote after reviewing the bug for appropriateness and risk.
    • June 22
    Do zip, update, site preparations
    • June 29
    Release

Ramp down for Europa SR1 (28-Sep-2007)

Since we expect to see only bug fixes without functional change in the TM 2.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.

The last few weeks before the TM 2.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 30th, RC1 produced
After Aug 30th, we'll have an intensive TM 2.0.1 Testing pass and fork off a mainenance branch for 2.0.1. 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.
  • Sep 6th, RC2 produced
After Sep 6th, 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. With RC2, we will fork off the R2_0_maintenance branch for further 2.0.1 work. Fixes after RC2 need to be applied to both the MAIN trunk and the R2_0_maintenance branch.
  • Sep 13th, RC3 produced
After Sep 13th, we do not really want to put any more bug fixes into 2.0.1 unless an emergency turns up. Time is reserved for our DSDP/TM/Face-to-face Meeting Toronto 17-Sep-2007, and release preparations. After Sep 13th, 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.

Ramp down for Europa SR2 (29-Feb-2007)

Back to the top