Jump to: navigation, search

Difference between revisions of "RAP/Ramp down plan"

< RAP
m (Backporting fixes for service releases)
(Ramp down plan)
(One intermediate revision by the same user not shown)
Line 4: Line 4:
 
For milestones, the component lead (or delegate) is enough to review and approve a bug.  
 
For milestones, the component lead (or delegate) is enough to review and approve a bug.  
  
'''For M6, we plan to be API complete''', so there will not be any more breaking API changes or unsolicited API change requests accepted.
+
'''M6 is API freeze''', no more breaking API changes should be committed after this milestone.
  
'''After RC1 is produced''', the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:
+
'''M7 is feature freeze''', no changes in behaviour should should be done after this release. The time after M7 should be used only for bug fixes.
 +
 
 +
'''After RC1''', only the following types of bug fixes are acceptable:
 
* A regression
 
* A regression
* A P1 or P2 bug, one that is blocking or critical, and some cases of major severities.  
+
* 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).  
+
* 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.  
+
* 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 project members to review.
 
* 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 project members to review.
** After RC1: Another committer from the project must review and vote + using Bugzilla (see below).
+
** '''After RC1''': Another committer from the project must review and vote +1 using Bugzilla (see below).
** After RC2: Another committer from the project and a project lead must review and vote +1 after reviewing the bug for appropriateness and risk.
+
** '''After RC2''': Another committer from the project and a project lead must review and vote +1 after reviewing the bug for appropriateness and risk.
  
 
== Bugzilla Usage for RC Fixes ==
 
== Bugzilla Usage for RC Fixes ==
Line 30: Line 32:
  
 
== See Also ==
 
== See Also ==
 
+
* [[Simultaneous_Release]]
 +
* [[Indigo]]
 
* [[Galileo Simultaneous Release]]
 
* [[Galileo Simultaneous Release]]
 
* [[Helios Simultaneous Release]]
 
* [[Helios Simultaneous Release]]

Revision as of 14:27, 21 May 2012

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.

M6 is API freeze, no more breaking API changes should be committed after this milestone.

M7 is feature freeze, no changes in behaviour should should be done after this release. The time after M7 should be used only for bug fixes.

After RC1, only the following types of bug fixes are acceptable:

  • 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 project members to review.
    • After RC1: Another committer from the project must review and vote +1 using Bugzilla (see below).
    • After RC2: Another committer from the project and a project lead must review and vote +1 after reviewing the bug for appropriateness and risk.

Bugzilla Usage for RC Fixes

Committers can signify their approval for submitting fixes as required after RC1 by simply indicating +1 in a comment.

Bugzilla has a flag feature that is to be used for obtaining PMC approval. Enter the email address of the PMC member you are requesting approval from and submit. The PMC member is notified via email and will change the flag from '?' to '+' or '-' as appropriate.

Backporting fixes for service releases

  • Bugfixes should be backported to the maintenance branch only if they match the criteria above.
  • A review is required if bug fixes should be backported.
  • A patch must be attached to every bug which is backported.
  • If a bug has been backported for a service release, a tag of the form "srNNN" must be added to the status whiteboard field in bugzilla, where NNN is the service release number without dots (e.g. "sr131" for RAP 1.3.1).
  • To request backporting for a service release, a tag of the form "srNNN?" can be used.

See Also