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

TPTP Project Ramp Down Policy for Galileo

Revision as of 13:19, 23 February 2009 by Jcayne.ca.ibm.com (Talk | contribs) (New page: == Ramp down for Galileo == For reference, see the Galileo Simultaneous Release, in particular the [[Galileo_Simultaneous_Release#Milestones_and_Releas...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Ramp down for Galileo

For reference, see the Galileo Simultaneous Release, in particular the Milestones and Release Candidates and the TPTP 4.5.3 Detailed schedule.

Typically, the last week of a milestone is for testing, and only fixing regressions and P1 or blocking defects. For milestones, the Project Lead (or delegate) is enough to review and approve a bug (refer to TPTP project matrix for Project leads).

For M6, we plan to be functionally, UI and API complete and the remaining Release Candidates are for fixing bugs, or release required items (such as version numbers, licensing, copyright, etc.).

For M7, we plan to be feature complete.

Beginning in M7 until RC1 is released, we expect each Project Lead (or delegate) to review and verify their teams' bugs.

After the first RC is produced, other RCs will be produced weekly, if needed, corresponding to the Galileo RC drop schedule and dropped to the Galileo staging update site.

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 severity.
  • 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 plug-ins, 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, benefit-to-risk ratio criteria is higher requiring PMC approval.

Dates:

  • May 19, RC1 produced
After May 19th, besides the normal component team review, at least 1 PMC member must also review and vote +1 after reviewing the bug for appropriateness and risk.
  • May 26, RC2 produced, if necessary
  • June 2, RC3 produced, if necessary
  • June 9, RC4 produced, if necessary
  • June 17
Do zip, TPTP and Galileo update site, and website preparations
  • June 26
Release


Exceptions to being Feature Complete in M6

This section lists features in plan for Galileo that did not make M6, as planned. All these features can be finished up in the RC1 cycle and will be included in RC1. In preparation for delivering a translatable release and closing on the new function in the time line we had planned for, we had made sure that all of the new properties strings used in the UI by these enhancements are checked in before April 17. New strings generated after this time will be reviewed and approved using the must-fix approval process.

The following main features are still to be completed during RC1.

  • TPTP Platform Project
  • TPTP Test Project
  • TPTP Trace and Profiling Project
  • Monitoring Project

Back to the top