Jump to: navigation, search

Difference between revisions of "FeatureFreeze"

Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
= Feature Freeze (FF) =
+
= Feature Freeze =
  
[[FeatureFreeze]] (FF) is one of the milestones in [[Release|OpenStack's release schedule]]. Like all freezes, it happens at the end of the day (or 23:59 PST).
+
[[FeatureFreeze]] (FF) happens when we create the milestone-proposed branch for the last development milestone in a cycle. It generally happens late on the Tuesday (or early on the Wednesday) on the corresponding milestone delivery week.
  
 
== Freeze ==
 
== Freeze ==
  
Once FF kicks in, you are no longer allowed to merge branches containing new features into the current development release. Such branches should be rejected by the review team.
+
Once FF kicks in, you are no longer allowed to merge branches containing new features into the current development release. Such branches should be rejected by the review team and postponed until the next series development opens (which should happen when RC1 is published).
  
 
== Rationale ==
 
== Rationale ==
  
FF ensures that sufficient share of the [[ReleaseCycle]] is dedicated to QA. Limiting the changes that affect the behavior of the software allow for consistent testing and efficient bugfixing.
+
FF ensures that sufficient share of the [[ReleaseCycle]] is dedicated to QA, until we produce the first release candidates. Limiting the changes that affect the behavior of the software allow for consistent testing and efficient bugfixing.
 
 
FF occurs one week after [[BranchMergeProposalFreeze]], to give time for reviewers to provide feedback and for developers to incorporate that feedback, before the branch gets merged.
 
  
 
== Exception procedure ==
 
== Exception procedure ==
Line 19: Line 17:
  
 
* Make sure all your changes have thorough unit tests, ''especially'' if your patch touches an area of the code that currently is not well-tested
 
* Make sure all your changes have thorough unit tests, ''especially'' if your patch touches an area of the code that currently is not well-tested
* Link the branch to the associated blueprint (if any)
+
* Make sure the proposed change is linked to the associated blueprint (if any)
 
* Propose your branch for merging
 
* Propose your branch for merging
* In a specific comment on the merge proposal, provide the following information:
+
* In a specific comment on the review, provide the following information:
 
** Benefit of the branch
 
** Benefit of the branch
 
** Risk of regression
 
** Risk of regression
* In the merge proposal, "Request a review" from the Release Manager and set review type to "FFE"
+
* In the review, request the advice of the Release Manager by adding his name using "Add reviewer"
  
 
You can check who is the current Release Manager by looking at the current [[Release|Release schedule]].
 
You can check who is the current Release Manager by looking at the current [[Release|Release schedule]].
  
 
The Release manager, with the assistance of the core developers of the associated product, will evaluate the request and grant or deny the exception. The farther we are in the release cycle, the less likely it is for the exception to be granted. Remember that the next cycle is just a month away :)
 
The Release manager, with the assistance of the core developers of the associated product, will evaluate the request and grant or deny the exception. The farther we are in the release cycle, the less likely it is for the exception to be granted. Remember that the next cycle is just a month away :)

Revision as of 11:06, 7 February 2013

Feature Freeze

FeatureFreeze (FF) happens when we create the milestone-proposed branch for the last development milestone in a cycle. It generally happens late on the Tuesday (or early on the Wednesday) on the corresponding milestone delivery week.

Freeze

Once FF kicks in, you are no longer allowed to merge branches containing new features into the current development release. Such branches should be rejected by the review team and postponed until the next series development opens (which should happen when RC1 is published).

Rationale

FF ensures that sufficient share of the ReleaseCycle is dedicated to QA, until we produce the first release candidates. Limiting the changes that affect the behavior of the software allow for consistent testing and efficient bugfixing.

Exception procedure

If you want to propose a branch containing a feature (that you believe has an acceptable importance/risk_of_regression ratio) for merging into the development release after FF, follow those steps:

  • Make sure all your changes have thorough unit tests, especially if your patch touches an area of the code that currently is not well-tested
  • Make sure the proposed change is linked to the associated blueprint (if any)
  • Propose your branch for merging
  • In a specific comment on the review, provide the following information:
    • Benefit of the branch
    • Risk of regression
  • In the review, request the advice of the Release Manager by adding his name using "Add reviewer"

You can check who is the current Release Manager by looking at the current Release schedule.

The Release manager, with the assistance of the core developers of the associated product, will evaluate the request and grant or deny the exception. The farther we are in the release cycle, the less likely it is for the exception to be granted. Remember that the next cycle is just a month away :)