Jump to: navigation, search

Difference between revisions of "DepFreeze"

m (Freeze)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
[[DepFreeze]] (DF) generally happens at the same time as [[FeatureFreeze]]. It ends when all projects completed their RC1 publication and have a proposed/* release branch.
+
[[DepFreeze]] (DF) generally happens at the same time as [[FeatureFreeze]]. It is followed generally a week later by the stricter [[AllDepFreeze]].
  
 
=== Freeze ===
 
=== Freeze ===
  
Once DF kicks in, you are no longer allowed to accept proposed changes containing new requirements to the '''openstack/requirements''' repository. Such proposed changes should be temporarily rejected by the review team and postponed until the next series development opens (which should happen when all RC1s have been published). Upgrades to existing Oslo libraries and OpenStack python client libraries are generally considered alright (see below).
+
Once DF kicks in, special rules apply to proposed changes to the '''openstack/requirements''' repository:
 +
 
 +
# additions or bumps corresponding to same-series releases of existing python-* client or oslo libraries or OpenStack middleware libraries: OK
 +
# bumps for existing, external dependencies: REQUIRES EXCEPTION (could be granted if the corresponsing bugfix is worth it)
 +
# additions of new external dependencies: NO (except in very extreme cases where the new dep is required to fix a *critical* bug)
 +
 
 +
Changes in the 2nd and 3rd categories should be temporarily rejected using a -2 vote to prevent them from being accidentally approved without an exception being granted.
 +
 
  
 
=== Rationale ===
 
=== Rationale ===
Line 10: Line 17:
 
DF facilitates the work of downstream OpenStack packagers by not gratuitously adding dependencies toward the end of the cycle, when they don't have as much time and freedom to add new dependencies to their distribution. It helps ensuring the timely packaging of OpenStack releases in distributions.
 
DF facilitates the work of downstream OpenStack packagers by not gratuitously adding dependencies toward the end of the cycle, when they don't have as much time and freedom to add new dependencies to their distribution. It helps ensuring the timely packaging of OpenStack releases in distributions.
  
=== General rules for requirements reviewers ===
 
 
* additions or bumps corresponding to same-series releases of existing python-* client or oslo libraries or OpenStack middleware libraries: YES
 
* bumps for existing, external dependencies: REQUIRES EXCEPTION (could be granted if the corresponsing bugfix is worth it)
 
* additions of new external dependencies: NO (except very extreme cases where the new dep is required to fix a *critical* bug)
 
  
 
=== Exception procedure ===
 
=== Exception procedure ===
  
If you want to propose requirements changes during DF (that is, if you believe has an acceptable benefit/disruption ratio), you should first raise an openstack-dev ML thread with '''[depfreeze]''' in the subject line (in addition to the affected project), discussing the proposed change and its merits. If the thread validates the approach, you can propose a change, referencing the discussion.
+
If you want to propose an exceptional requirements changes during DF (that is, if you believe has an acceptable benefit/disruption ratio), you should first raise an openstack-dev ML thread with '''[depfreeze]''' in the subject line (in addition to the affected project), discussing the proposed change and its merits. If the thread validates the approach, you can propose a change, referencing the discussion.
  
 
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 :)
  
 
[[Category: ContribDocs]]
 
[[Category: ContribDocs]]

Revision as of 12:41, 20 March 2015

DepFreeze (DF) generally happens at the same time as FeatureFreeze. It is followed generally a week later by the stricter AllDepFreeze.

Freeze

Once DF kicks in, special rules apply to proposed changes to the openstack/requirements repository:

  1. additions or bumps corresponding to same-series releases of existing python-* client or oslo libraries or OpenStack middleware libraries: OK
  2. bumps for existing, external dependencies: REQUIRES EXCEPTION (could be granted if the corresponsing bugfix is worth it)
  3. additions of new external dependencies: NO (except in very extreme cases where the new dep is required to fix a *critical* bug)

Changes in the 2nd and 3rd categories should be temporarily rejected using a -2 vote to prevent them from being accidentally approved without an exception being granted.


Rationale

DF facilitates the work of downstream OpenStack packagers by not gratuitously adding dependencies toward the end of the cycle, when they don't have as much time and freedom to add new dependencies to their distribution. It helps ensuring the timely packaging of OpenStack releases in distributions.


Exception procedure

If you want to propose an exceptional requirements changes during DF (that is, if you believe has an acceptable benefit/disruption ratio), you should first raise an openstack-dev ML thread with [depfreeze] in the subject line (in addition to the affected project), discussing the proposed change and its merits. If the thread validates the approach, you can propose a change, referencing the discussion.

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 :)