Difference between revisions of "Modeling Project Ramp Down Policy/Europa"

From Eclipsepedia

Jump to: navigation, search
 
m (Modeling Project Ramp Down Policy moved to Modeling Project Ramp Down Policy/Europa: time for ganymede, ya'll biscuitheads)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Ramp down for Europa ==  
+
== Ramp Down for Europa ==  
 +
 
 +
This ramp down policy applies to those Modeling projects taking part in the Europa release of Eclipse projects.  Currently, the following projects are included:
 +
 
 +
* Eclipse Modeling Framework (EMF), including EMF Query/Transaction/Validation: +1 week from platform
 +
* Graphical Modeling Framework (GMF): +2 weeks from platform
 +
* Model Development Tools (MDT), includes UML2, OCL, XSD, EODM, UML2 Tools: +2 weeks from platform
  
 
For reference, see the [[Europa Simultaneous Release]],
 
For reference, see the [[Europa Simultaneous Release]],
 
in particular the [[Europa_Simultaneous_Release#Milestones_and_Release_Candidates | Milestones and Release Candidates]].  In the case of Modeling projects, the dates below represent the last (+2 week) project release dates.  +1 week projects (e.g. EMF) are expected the prior week in accordance with the schedule above.
 
in particular the [[Europa_Simultaneous_Release#Milestones_and_Release_Candidates | Milestones and Release Candidates]].  In the case of Modeling projects, the dates below represent the last (+2 week) project release dates.  +1 week projects (e.g. EMF) are expected the prior week in accordance with the schedule above.
  
Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects.
+
Note that while these staggered dates apply to early development milestones, as Release Candidates are produced the time in between should naturally decrease until the final 'simultaneous' release on June 29th.
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 (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).
+
== Ramp Down Details ==
  
From M6 to RC1 on May 18th, we expect each component lead (or delegate) to review and verify their teams' bugs.
+
Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects. For M6, we plan to be functionally and API complete and the remaining Release Candidates are (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).  Up to this point, Committers are expected to follow the normal Eclipse development practices when committing code.
  
After the first RC is produced, other RCs will be produced, if needed, every week.  
+
For M7/RC0 to RC1, we expect each component lead (or delegate) to review and verify their teams' bugs.
  
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:  
+
After RC1 is produced, the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:
<ol>
+
 
* 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 PMC 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 PMC members to review. As it is the Modeling project's practice to have each Project Lead on the PMC, getting approval to required fixes through RC2 should involve minimal overhead.
<ol>
+
** After RC1 (May 23rd for +1, May 25th for +2): At least 1 PMC member (typically, the Project Lead) must review and vote + using the Bugzilla flag feature (see below).
* May 18th, RC 1 produced
+
** After RC2 (May 30th for +1, June 5th for +2): Another Committer from the component or project and at least 1 PMC member must review and vote +1 after reviewing the bug for appropriateness and risk.
 
+
** After RC3 (June 13th for +1, June 14th for +2): Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk.
:After the 18th, 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.
+
** June 22: Do zip, update, site preparations
 
+
** June 29: Release
* May 25
+
 
+
 
+
* June 1
+
 
+
:After June 1, besides the normal component team review, at least 2 PMC members must also review and vote +1 after reviewing the bug for appropriateness and risk.
+
 
+
* June 8
+
 
+
 
+
* June 15
+
 
+
:After the 15th, besides the normal component team review, at least 3 PMC member must also review and vote +1 after reviewing the bug for appropriateness and risk.
+
 
+
* June 22
+
  
:Do zip, update, site preparations
+
== Bugzilla Usage for RC Fixes ==
 +
Committers can signify their approval for submitting fixes as required after RC2 by simply indicating +1 in a comment.
  
* June 29
+
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.
  
:Release
+
[[Category:Modeling]] [[Category:Modeling Project Management]]
</ol></ol>
+

Latest revision as of 15:18, 23 April 2008

[edit] Ramp Down for Europa

This ramp down policy applies to those Modeling projects taking part in the Europa release of Eclipse projects. Currently, the following projects are included:

  • Eclipse Modeling Framework (EMF), including EMF Query/Transaction/Validation: +1 week from platform
  • Graphical Modeling Framework (GMF): +2 weeks from platform
  • Model Development Tools (MDT), includes UML2, OCL, XSD, EODM, UML2 Tools: +2 weeks from platform

For reference, see the Europa Simultaneous Release, in particular the Milestones and Release Candidates. In the case of Modeling projects, the dates below represent the last (+2 week) project release dates. +1 week projects (e.g. EMF) are expected the prior week in accordance with the schedule above.

Note that while these staggered dates apply to early development milestones, as Release Candidates are produced the time in between should naturally decrease until the final 'simultaneous' release on June 29th.

[edit] Ramp Down Details

Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects. For M6, we plan to be functionally and API complete and the remaining Release Candidates are (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.). Up to this point, Committers are expected to follow the normal Eclipse development practices when committing code.

For M7/RC0 to RC1, we expect each component lead (or delegate) to review and verify their teams' bugs.

After RC1 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 PMC members to review. As it is the Modeling project's practice to have each Project Lead on the PMC, getting approval to required fixes through RC2 should involve minimal overhead.
    • After RC1 (May 23rd for +1, May 25th for +2): At least 1 PMC member (typically, the Project Lead) must review and vote + using the Bugzilla flag feature (see below).
    • After RC2 (May 30th for +1, June 5th for +2): Another Committer from the component or project and at least 1 PMC member must review and vote +1 after reviewing the bug for appropriateness and risk.
    • After RC3 (June 13th for +1, June 14th for +2): Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk.
    • June 22: Do zip, update, site preparations
    • June 29: Release

[edit] Bugzilla Usage for RC Fixes

Committers can signify their approval for submitting fixes as required after RC2 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.