Difference between revisions of "Nova/Liberty Release Schedule"
John Garbutt (talk | contribs) m (→Dates overview) |
John Garbutt (talk | contribs) m (→Dates overview) |
||
| Line 13: | Line 13: | ||
* August 17-21: Feature Proposal Freeze | * August 17-21: Feature Proposal Freeze | ||
* September 1-3: liberty-3 -- align with string freeze, etc, open specs for M | * September 1-3: liberty-3 -- align with string freeze, etc, open specs for M | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Feature Freeze === | === Feature Freeze === | ||
| Line 54: | Line 35: | ||
As with all processes here, there are exceptions. But the exceptions at this stage need to be discussed with the horizontal teams that might be affected by changes beyond this point, and as such are discussed with one of the OpenStack release managers. | As with all processes here, there are exceptions. But the exceptions at this stage need to be discussed with the horizontal teams that might be affected by changes beyond this point, and as such are discussed with one of the OpenStack release managers. | ||
| + | |||
| + | === Spec and Blueprint Approval Freeze === | ||
| + | |||
| + | This is a (mostly) nova specific process. | ||
| + | |||
| + | Why do we have a Spec Freeze: | ||
| + | * specs take a long time to review, keeping it open distracts from code reviews | ||
| + | * keeping them "open" and being slow at reviewing the specs (or just ignoring them) really annoys the spec submitters | ||
| + | * we generally have more code submitted that we can review, this time bounding is a way to limit the number of submissions | ||
| + | |||
| + | By the freeze date, we expect this to also be the complete list of approved blueprints for liberty: | ||
| + | https://blueprints.launchpad.net/nova/liberty | ||
| + | |||
| + | The date listed above is when we expect all specifications for Liberty to be merged and displayed here: | ||
| + | http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/ | ||
| + | |||
| + | New in Liberty, we will keep the backlog open for submission at all times. Note: the focus is on accepting and agreeing problem statements as being in scope, rather than queueing up work items for the M release: | ||
| + | http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html | ||
| + | |||
| + | There can be exceptions, usually its an urgent feature request that comes up after the initial deadline. These will generally be discussed at the weekly Nova meeting, by adding the spec or blueprint to discuss in the appropriate place in the meeting agenda here (ideally make yourself available to discuss the blueprint, or alternatively make your case on the ML before the meeting): | ||
| + | https://wiki.openstack.org/wiki/Meetings/Nova | ||
=== Non-priority Blueprint Feature Freeze === | === Non-priority Blueprint Feature Freeze === | ||
Revision as of 14:37, 9 June 2015
We are aligning with: Liberty_Release_Schedule
But there are some extra deadlines to around Priority features.
Contents
Dates overview
- June 23-25: liberty-1 -- spec freeze for L, backlog stays open
- July 13-17: non-priority feature proposal freeze
- July 21-23: mid-cycle meetup
- July 28-30: liberty-2 -- non-priority feature freeze
- August 17-21: Feature Proposal Freeze
- September 1-3: liberty-3 -- align with string freeze, etc, open specs for M
Feature Freeze
This effort is primarily to help the horizontal teams help prepare their items for release, while at the same time giving developers time to focus on stabilising what is currently in master, and encouraging users and packages to perform tests (automated, and manual) on the release, to spot any major bugs.
As such we have the following processes:
- https://wiki.openstack.org/wiki/FeatureProposalFreeze
- make sure all code is up for review
- so we can optimise for completed features, not lots of half completed features
- https://wiki.openstack.org/wiki/FeatureFreeze
- make sure all feature code is merged
- https://wiki.openstack.org/wiki/StringFreeze
- give translators time to translate all our strings
- Note: debug logs are no longer translated
- https://wiki.openstack.org/wiki/DepFreeze
- time to co-ordinate the final list of deps, and give packagers time to package them
- generally it is also quite destabilising to take upgrades (beyond bug fixes) this late
We align with this in Nova and the dates for this release are stated above.
As with all processes here, there are exceptions. But the exceptions at this stage need to be discussed with the horizontal teams that might be affected by changes beyond this point, and as such are discussed with one of the OpenStack release managers.
Spec and Blueprint Approval Freeze
This is a (mostly) nova specific process.
Why do we have a Spec Freeze:
- specs take a long time to review, keeping it open distracts from code reviews
- keeping them "open" and being slow at reviewing the specs (or just ignoring them) really annoys the spec submitters
- we generally have more code submitted that we can review, this time bounding is a way to limit the number of submissions
By the freeze date, we expect this to also be the complete list of approved blueprints for liberty: https://blueprints.launchpad.net/nova/liberty
The date listed above is when we expect all specifications for Liberty to be merged and displayed here: http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/
New in Liberty, we will keep the backlog open for submission at all times. Note: the focus is on accepting and agreeing problem statements as being in scope, rather than queueing up work items for the M release: http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
There can be exceptions, usually its an urgent feature request that comes up after the initial deadline. These will generally be discussed at the weekly Nova meeting, by adding the spec or blueprint to discuss in the appropriate place in the meeting agenda here (ideally make yourself available to discuss the blueprint, or alternatively make your case on the ML before the meeting): https://wiki.openstack.org/wiki/Meetings/Nova
Non-priority Blueprint Feature Freeze
This is a nova specific process.
We currently have a very finite amount of review bandwidth. In order to make code review time for the agreed community wide priorities, we have to not do some other things. To this end, we are reserving liberty-3 for priority features and bug fixes. As such, we indent not to merge any non-priority things during liberty-3, so liberty-2 is the "Feature Freeze" for blueprints that are not a priority for liberty.
You can see the list of priorities for each release: http://specs.openstack.org/openstack/nova-specs/#priorities
For things that are very close to merging, its possible it might get an exception for one week after the freeze date, given the patches get enough +2s from the core team to get the code merged. But we expect this list to be zero, if everything goes to plan (no massive gate failures, etc).
Alternatives:
- It was hoped to make this a continuous process using "slots" to control what gets reviewed, but this was rejected by the community when it was last discussed. There is hope this can be resurrected to avoid the "lumpy" nature of this process.
Special review days
- June 12: spec review day (to be confirmed)
- July 10: feature review bash day (to be confirmed)
- August 7: bug triage day (to be confirmed)
- September 11: bug review bash day (to be confirmed)
How to get my feature merged?
TODO
Why bother?
We have agreed a list of priorities for the release here: http://specs.openstack.org/openstack/nova-specs/#priorities
Over previous release it became clear there are things we have to stop doing, to enable enough developer effort and review bandwidth to focus on priorities.
If people are not working on priorities, its hoped they can either start helping some some of the priority efforts, or assist with bug fixing and bug triage.
