This page to be developed. Rather than establish a project for OpenStack the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities.

Information we should get up here asap:

do stuff here.

stuff here about lifecycle links to the templates

New table structure:

Blueprint status can be "Work in progress" (blueprint being actively edited), "Under review" (blueprint is final and submitted for review), "Approved" (approved for inclusion, development work not yet started), "In development", "Completed" (work accepted upstream), "Rejected" (not approved for inclusion), "Deferred" (to be submitted for next release).

If you have a blueprint which you would like reviewed, contact Dave Neary dneary@redhat.com or email opnfv-tech-discuss@lists.opnfv.org to schedule a review on the weekly technical review call. This process is likely to evolve soon.

Relevant process pages:

• Release cycle
• Blueprint documentation
• Kilo release cycle
• Nova Liberty blueprint template

A good blueprint has the following characteristics:

• Explains the context of the blueprint - the high level use-case which requires the feature
• Explains the feature request in a generic, non-NFV-specific manner
• Provides some specification details on how the feature will be implemented
• Uses the project's spec template (located in specs/template.rst of the project "specs" repo, typically)

This provides the material for an informed, useful discussion upstream of the feature and whether the proposed approach is the best way to accomplish the high level goal.

It is possible to get code into OpenStack without going through the Blueprint process by submitting a patch for review directly, but it does not make it easier to get the code accepted.

From Release Cycle document upstream:

The Planning stage is at the start of a cycle, just after the
previous release, when we take a step back and focus on what we want
to do for the next one. We discuss it with our peers to get their
feedback and comments, in most cases proposing a spec document that
precisely describes how we want to do it. It usually lasts 4 weeks,
with the Design Summit on the third week.

In general, the review period has lasted until the first milestone release, between 6 and 8 weeks after the previous release.

Key dates for Kilo (with special attention on Nova):

• Sept 30: Juno release date
• Sept 30 - Dec 18: Kilo planning
• Oct 7: Nova Kilo specs open for review
• Week of Nov 6: Paris summit
• Dec 18: kilo-1 milestone, Nova spec approval soft deadline
• Jan 22: Nova non-priority feature code proposal, Nova spec hard deadline
• Feb 5: kilo-2 milestone, Nova & Cinder non-priority feature freeze
• Mar 5: Feature proposal freeze
• Mar 19: kilo-3 milestone, feature, string and dependency freeze
• April 30: Kilo release

The Nova team is being even more proactive in Liberty than they were in Kilo. The March 1st date you have been hearing is because Nova Liberty specs are now open for review.

In practice: specs for the Liberty release should be proposed and pre-discussed in advance of the Vancouver summit (May 18-22). There may be some benefit in uploading specs for Liberty now to gain alignment inside OPNFV and refine them, but in the email above, Michael Still (Nova PTL) was clear that he does not expect serious spec review to start until Kilo is out the door on April 30th.

Other projects operate on their own schedule, and have different criteria for when they expect specs to be proposed and approved. For most of them, Liberty blueprint review will not start until after the Kilo release.

Blueprints should be discussed and reviewed online in advance of Vancouver, and advocated for the design summit working sessions, to ensure they are included in scope for Liberty. Blueprints proposed after the Vancouver Summit are not eliminated, but will have a hard time being approved for Liberty.

As a general rule of thumb, the earlier in the cycle you engage with the project teams, the more time you have for features and fixes to land in the release. Make sure that code starts coming in as soon as the spec is approved, as there are cases where time is spent on specs and then code shows up too late to be reviewed in time anyway.

Much of this is in flux, or under discussion - while things should be stable for the Liberty release cycle, changes should be expected in coming releases:

• Dan Berrange's proposal to shorten release cycle:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html

• Thierry Carrez's report on the state of project reform:

https://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/

Some additional links on successfully shepherding blueprints through review:

• Rob Hirschfeld's description of the release cycle
• A presentation from Hong Kong on navigating the blueprint process

Many members of the OPNFV group are active in the Telco working group in OpenStack.

• joe.stacker@opngv.org

to be completed…