Jump to: navigation, search

Difference between revisions of "Nova/Liberty Release Schedule"

m (→‎Interaction goals)
m (→‎Interaction goals)
Line 166: Line 166:
 
* we want a way for everyone to review blueprints and designs, including allowing for input from operators and all types of users
 
* we want a way for everyone to review blueprints and designs, including allowing for input from operators and all types of users
 
* we need to take care to not expand Nova's scope any more (unless absolutely necessary)
 
* we need to take care to not expand Nova's scope any more (unless absolutely necessary)
−
* any API we release, we must support (approx) for ever, and we currently release every commit, so we best get the API right first time
+
* need to ensure we get sufficient focus on the core of Nova so its easy to add new features, as required
 +
* any API we release, we must support (approx.) for ever, and we currently release every commit, so we best get the API right first time
 
* need to avoid low priority blueprints slowing work on high priority work, but ideally only ever blocked for a single cycle, and those blocked should be able to help unblock
 
* need to avoid low priority blueprints slowing work on high priority work, but ideally only ever blocked for a single cycle, and those blocked should be able to help unblock
 +
* focus on a consistent experience for our users, rather than ease of development
 
* optimise for completed blueprints, rather than more half completed blueprints, so we get maximum value for our users out of our review bandwidth
 
* optimise for completed blueprints, rather than more half completed blueprints, so we get maximum value for our users out of our review bandwidth
 
* focused core reviewers tend to be more productive, and get more things merged, so try to focus efforts on a subset of patches
 
* focused core reviewers tend to be more productive, and get more things merged, so try to focus efforts on a subset of patches

Revision as of 15:09, 6 July 2015

We are aligning with: Liberty_Release_Schedule

But there are some extra deadlines around Priority features.

Dates overview

  • June 23-25: liberty-1 -- spec freeze for L, backlog stays open
  • July 16: non-priority feature proposal freeze
  • July 21-23: mid-cycle meetup
  • July 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


OpenStack wide tracking of current progress: http://status.openstack.org/release/

Special review days

To make the above gates go smoother, we have some big review pushes:


All of these involve hanging out in #openstack-nova and working together to try and improve the statistics mentioned above.

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?

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 need a blueprint vs a spec?

For more details see:

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


If you are unsure, please ask johnthetubaguy on IRC, or one of the other nova-drivers.

How do I get my blueprint approved?

So you need your blueprint approved? Here is how:

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.

Process Mission and Goals

This section takes a high level look at the guiding principles behind the Nova process.

Open

Our mission is to have:

  • Open Source
  • Open Design
  • Open Development
  • Open Community


We have to work out to keep communication open in all areas. We need to be welcoming and mentor new people, and make it easy for them to pickup the knowledge they need to get involved with OpenStack. For more info on Open, please see: https://wiki.openstack.org/wiki/Open

Interoperable API and vibrant ecosystem

An interoperable API that gives uses on demand access to compute resources is at the heart of Nova's mission: http://docs.openstack.org/developer/nova/project_scope.html#mission

Nova has a vibrant ecosystem of tools built on top of the current Nova API. All features should be added such that they can work with all technology combinations, so the feature can be adopted by our ecosystem. If a new feature is not adopted by the ecosystem, it will make it hard for your users to make use of those features, defeating most of the reason to add the feature in the first place.

This is a very different aim to being "pluggable" or wanting to expose all capabilities to end users. To ensure we are not restricted to lowest common denominator APIs, the interoperable focus is more on End User APIs and not admin APIs.

Interaction goals

When thinking about the importance of process, we should take a look at: http://agilemanifesto.org

With that in mind, lets look at how we want different members of the community to interact. Lets start with looking at issues we have tried to resolve in the past:

  • we want a way for everyone to review blueprints and designs, including allowing for input from operators and all types of users
  • we need to take care to not expand Nova's scope any more (unless absolutely necessary)
  • need to ensure we get sufficient focus on the core of Nova so its easy to add new features, as required
  • any API we release, we must support (approx.) for ever, and we currently release every commit, so we best get the API right first time
  • need to avoid low priority blueprints slowing work on high priority work, but ideally only ever blocked for a single cycle, and those blocked should be able to help unblock
  • focus on a consistent experience for our users, rather than ease of development
  • optimise for completed blueprints, rather than more half completed blueprints, so we get maximum value for our users out of our review bandwidth
  • focused core reviewers tend to be more productive, and get more things merged, so try to focus efforts on a subset of patches
  • ideally tell people sooner, rather than later, that their work is unlikely to get reviewed in a particular cycle, to avoid sitting in an expensive rebase loop

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.

If you have a problem with a process, please engage with the community, discover the reasons behind our current process, and help fix the issues you are experiencing.

Why do you not remove old process?

We do removal old process. Please see how in liberty we stopped trying to predict the milestones when a feature will land.

As we evolve, it is important to unlearn new habits, explore if things get better if we choose to optimise for a different set of issues.

Why are specs useful?

Specs reviews allow anyone to step up an contribute to reviews, just like with code. Before we used gerrit, it was a very messy review process, that felt very "closed" to most people involved in that process.

As Nova has grown in size, it can be hard to work out how to modify Nova to meet your needs. Specs are a great way of having that discussion with the wider Nova community.

For Nova to be a success, we need to ensure we don't break our existing users. The spec template helps focus the mind on the impact your change might have on exisitng users, and gives an opportunity to discuss the best way to deal with those issues.

However, there are some pitfalls with the process. Here are some top tips to avoid them:

  • keep it simple, shorter, simpler decomposed specs are much quicker to review and merge much quicker (just like code patches)
  • specs can help with documentation, but they are only intended to document the design discussion, rather than document the final code
  • don't add details that are best reviewed in code, almost always best leaving those things for the code review

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.

Why is there a Feature Freeze (and String Freeze) in Nova?

The main reason Nova has a feature freeze, as it gives people working on docs and translations to sync up with the latest code. Traditionally this happens at the same time across multiple projects, so the docs are synced between what used to be called the "integrated release".

We also use this time period as an excuse to focus our development efforts on bug fixes, ideally lower risk bug fixes, and improving test coverage.

In theory, with a waterfall hat on, this would be a time for testing and stabilisation of the product. In Nova we have a much stronger focus on keeping every commit stable, by making use of extensive continuous testing. In reality, we frequently see the biggest influx of fixes in the few weeks after the release, as distributions do final testing of the released code.

It is hoped the work on Feature Classification will lead us to better understand the levels of testing of different Nova features, so we will be able to reduce and dependency between Feature Freeze and regression testing. It is also likely that the move away from "integrated" releases will help find a more developer friendly approach to keep the docs and translations in sync.

Why is there a non-priority Feature Freeze in Nova?

We have already discussed why we have priority features.

The Nova project, while growing at a surprisingly fast rate, still has a limited ability to merge code, due to the amount of people willing to commit time to review code. Given this fixed capacity, making something a priority, means not doing something else.

The simplest way to make space for the priority features is to stop reviewing and merging non-priority features for a whole milestone. The idea being developers should focus on bug fixes and priority features during that milestone, rather than working on non-priority features.

A known limitation of this approach is developer frustration. Many developers are not being given permission to review code, work on bug fixes or work on priority features, and so feel very unproductive upstream. An alternative approach of "slots" or "runways" has been considered, that uses a kanban style approach to regulate the influx of work onto the review queue. We are yet to get agreement on a more balanced approach, so the existing system is being continued to ensure priority items are more likely to get the attention they require.

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