Difference between revisions of "MemoryAnalyzer/Ramp Down Plan"

From Eclipsepedia

Jump to: navigation, search
(New page: == 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 e...)
 
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.
+
'''For M7, we plan to be API and feature complete''', so there will be no breaking API changes and no new feature requests will be accepted.
  
'''After RC1 is produced''', the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:
+
'''For RC1 - RC2 only bugfixes to Memory Analyzer''' functionaliry should be done. The following describes the types of bugs that would be appropriate:
 
* 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
* 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).
+
* Minor documentation changes
* 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 + 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 ==
+
'''RC3 - RC4''' only bugfixes damaging the build/functionality of the simultaneous release should are allowed
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.
+
  
 
== See Also ==
 
== See Also ==

Revision as of 22:42, 31 March 2010

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 M7, we plan to be API and feature complete, so there will be no breaking API changes and no new feature requests will be accepted.

For RC1 - RC2 only bugfixes to Memory Analyzer functionaliry should be done. The following describes the types of bugs that would be appropriate:

  • A regression
  • A P1 or P2 bug, one that is blocking or critical
  • Minor documentation changes

RC3 - RC4 only bugfixes damaging the build/functionality of the simultaneous release should are allowed

See Also