Difference between revisions of "Nova/Liberty Release Schedule"
John Garbutt (talk | contribs) (→Why bother?) |
John Garbutt (talk | contribs) m (→How to get my feature merged?) |
||
| Line 83: | Line 83: | ||
== How to get my feature merged? == | == How to get my feature merged? == | ||
| − | + | OK, so you are new to Nova, and you have been given a feature to implement. How do I make that happen? | |
| + | |||
| + | So you can get most of your questions answered here: | ||
| + | * http://docs.openstack.org/infra/manual/developers.html | ||
| + | |||
| + | But lets put a Nova specific twist on things... | ||
| + | |||
| + | === Where do you track bugs? === | ||
| + | |||
| + | We track bugs here: | ||
| + | * http://bugs.launchpad.net/nova | ||
| + | |||
| + | If you fix an issue, please raise a bug so others that spot that issue can find the fix you kindly created for them. | ||
| + | |||
| + | Also, before submitting your patch, its worth checking to see if someone has already fixed it for you (launchpad helps you with that, at little, when you create the bug report). | ||
| + | |||
| + | === When do I always need to do a blueprint or spec? === | ||
| + | |||
| + | To understand this question, we need to understand why blueprints and specs are useful. | ||
| + | |||
| + | But here is a rough idea: | ||
| + | * if it needs a spec, it will need a blueprint | ||
| + | * if its an API change, it needs a spec | ||
| + | * if its a single small patch that touches a small amount of code, with limited deployer and doc impact, it probably doesn't need a spec | ||
| + | |||
| + | How do I get my blueprint approved: | ||
| + | * if you don't need a spec, please add a link to your blueprint to the agenda for the next nova meeting: https://wiki.openstack.org/wiki/Meetings/Nova | ||
| + | ** be sure your blueprint description has enough context for the review in that meeting | ||
| + | * if you need a spec, then please submit a nova-spec for review, see: http://docs.openstack.org/infra/manual/developers.html | ||
| + | |||
| + | For more details see: | ||
| + | * http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#when-is-a-blueprint-needed | ||
| + | |||
| + | Got any more questions? Contact johnthetubaguy on IRC for help, or one of the other nova-specs-core who are awake at the same time as you, or send him an email. | ||
== FAQs == | == FAQs == | ||
Revision as of 15:15, 9 June 2015
We are aligning with: Liberty_Release_Schedule
But there are some extra deadlines to around Priority features.
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
Special review days
To make the above gates go smoother, we have some big review pushes:
- 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)
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.
How to get my feature merged?
OK, so you are new to Nova, and you have been given a feature to implement. How do I make that happen?
So you can get most of your questions answered here:
But lets put a Nova specific twist on things...
Where do you track bugs?
We track bugs here:
If you fix an issue, please raise a bug so others that spot that issue can find the fix you kindly created for them.
Also, before submitting your patch, its worth checking to see if someone has already fixed it for you (launchpad helps you with that, at little, when you create the bug report).
When do I always need to do a blueprint or spec?
To understand this question, we need to understand why blueprints and specs are useful.
But here is a rough idea:
- if it needs a spec, it will need a blueprint
- if its an API change, it needs a spec
- if its a single small patch that touches a small amount of code, with limited deployer and doc impact, it probably doesn't need a spec
How do I get my blueprint approved:
- if you don't need a spec, please add a link to your blueprint to the agenda for the next nova meeting: https://wiki.openstack.org/wiki/Meetings/Nova
- be sure your blueprint description has enough context for the review in that meeting
- if you need a spec, then please submit a nova-spec for review, see: http://docs.openstack.org/infra/manual/developers.html
For more details see:
Got any more questions? Contact johnthetubaguy on IRC for help, or one of the other nova-specs-core who are awake at the same time as you, or send him an email.
FAQs
Why bother with all this process?
We are a large community, spread across multiple timezones, working with several horizontal teams. Good communication is a challenge, and the processes we have are mostly there to try and help fix some communication challenges.
Why do we have priorities?
To be clear, there is no "nova dev team manager", we are an open team of professional software developers, that all work for a variety of (mostly completing) companies that collaborate to ensure the Nova project is a success.
Over time, a lot of technical debt has accumulated, because there was a lack of collected ownership to solve those cross cutting concerns. Before the kilo release, it was noted that progress felt much slower, because we were unable to get appropriate attention on the architectural evolution of Nova. This was important, partly for major concerns like upgrades and stability. We agreed its something we all cared about, and needs to be given priority to ensure it these things get fixed.
The discussion at the summit, turns in to a spec review, which eventually means we get a list of priorities here: http://specs.openstack.org/openstack/nova-specs/#priorities
This does mean we need review bandwidth for all these efforts, which means the reviews needs to stop doing something else, to make time to review these priority items. This is mostly why we now have the non-priority Feature Freeze.
