Jump to: navigation, search

Difference between revisions of "Nova/Liberty Release Schedule"

m
(→‎Why bother?)
Line 85: Line 85:
 
TODO
 
TODO
  
−
== Why bother? ==
+
== FAQs ==
  
−
We have agreed a list of priorities for the release here: http://specs.openstack.org/openstack/nova-specs/#priorities
+
=== Why bother with all this process? ===
  
−
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.
+
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.
  
−
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.
+
=== 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.

Revision as of 14:48, 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:


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?

TODO

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.

Retrieved from "https://wiki.openstack.org/w/index.php?title=Nova/Liberty_Release_Schedule&oldid=82995"