This is an old revision of the document!
OR
Then
OPNFV will adopt a bi-annual (twice yearly) cadence derived primarily from the cadence of its major upstream constituents.
The SR plan recognizes the inherent layering in a set of deliverables, which requires that layer N be stable in order for layer N + 1 to begin to stabilize. The schedule accounts for such dependencies through the use of “offsets” between layers. For example, the first SR will have (at least) two layers:
Unless and until the upstream projects are proven to have been successfully pulled into the OPNFV repo and correctly built with the OPNFV tooling, there is little point in running the OPNFV local testing that is designed to go beyond the basic CI and release testing from upstream. For this reason, the date when we can expect to code freeze the basic platform tooling and code needs to occur prior to the code freeze for the layered system tests. To support this the SR has an Offset 0 milestone to freeze the platform bits, which is distinct and separate in time from the Offset 1 for that same milestone (code freeze). If we estimate that it will take two weeks to iterate and converge bug find/fix ratios in the code that constitutes the offset 1 deliverables, the schedule would reflect that by documenting the date for the offset 1 code freeze occurring two weeks later. Additional SR offsets can be proposed and incorporated on-demand, as OPNFV evolution dictates. If (hypothetical, currently out of scope) OPNFV were to begin releasing virtual network functions, it would make sense to create an offset between the system test completion and the completion of test/fix for the VNF “layer”.
Deadlines for Release Candidates (RC0, RC1 and RC1) and the release are the same regardless of offset. Deadlines for M1 and M2 are offset by +1 week and +2 weeks. Full details can be found in the dates in the specific SR schedule.
All of the commitments required of SR member projects shall be made known in writing in the simultaneous release plan on the OPNFV wiki before projects can apply to join. It is not fair to projects to change (and particularly to add) commitments after projects have agreed to participate. If we learn that additional SR requirements make sense, every effort should be made to treat them as suggestions in any ongoing SR, and to wait to make them requirements until the next SR planning stage.
The OPNFV SR plan must be approved by the OPNFV Technical Steering Committee before its terms become binding. Milestone 0, SR open for participation, must be scheduled at a date after the TSC has approved the SR plan. The TSC shall post one or more draft SR plans to inform community planning, but only the approved plan, dates and commitments are binding.
The first Release of OPNFV platform will be aimed at March 15, 2015. The basic approach for this release is to build all of the upstream stable projects and run some additional NFV-centric testing on the resulting artifacts. In support of this, the (draft) OPNFV SR 1.0 release plan is designed with Offset 0 and Offset 1 milestones.
These dates are included only to enable a community discussion about what the correct dates should be. In particular, we need to define M0 and M1 and agree to them in order to start the process and enable maximum time for the rest of the SR steps to occur.
Assumption below is that because this is the first release defined during the initial creation of the OPNFV processes and community, there are unique requirements that we will recognize including: • TSC has agreed our goal is keep it simple and do little more than pull together our upstream dependencies in a single “distribution” and demonstrate that the resulting system can be used to support “NFV” by some definition • TSC has sponsored creation of an initial set of projects related to systems and infrastructure that will be relied upon to turn the various source code and binary artifacts into the platform that is the output of OPNFV project. • The bootstrap capabilities provided by these initial projects means they, of course, need to be part of the first SR.
Milestone Offset 0 Offset 1 Event PP0 11/11/14 11/11/14 TSC Begins approving project proposals. M0 11/18/14 11/18/14 Simultaneous Release Open M1 12/2/14 12/09/14 1. Projects Must Have Declared their intent to participate in the simultaneous release
2. Participating projects must have published a candidate Release Plan for public comment ( Release Plan Template )
M2 12/16/14 12/23/14 Participating Projects must have declared their final Release Plan M3 12/23/14 12/30/14 Latest possible Continuous Integration Test Start M4 2/1/15 02/08/15 1. API Freeze
2/15/15 02/22/15 2. Latest possible Continuous System Test Start
M 5 2/1/15 1. Code Freeze (bug fixes only from here)
2. String Freeze (all internationalizable strings frozen to allow translation time) 3. Latest possible date for commencing User facing Documentations
RC0 2/22/15 03/01/15 First Release Candidate RC1 3/1/15 03/04/15 Second Release Candidate RC2 3/8/15 03/08/15 1. Final Release Candidate
2. Participating Projects must hold their Release Reviews, including User Facing Documentation.
FR 3/15/15 03/15/15 Formal Release MR0 4/15/15 04/15/15 First Maintenance Release MR1 6/14/15 06/14/15 Second Maintenance Release MR- N How Many MR do we want to show?
6 Months after our first and 3 months after Kilo we bring second OPNFV SR.
TBD
TBD
To avoid major surgery during the time when test/fix cycle is trying to converge we will define “quiet” times imposing constraints like API Freeze, Feature Freeze, and a series of release candidates. Dates for these milestones will be backed out of the release target dates and based on estimates of the work required. In a true “continuous delivery” environment it may turn out that the delta between grabbing the head of dev tree and shipping an SR may approach zero. The initial release will probably need to support some element of non-automated testing and will need an appropriate cycle time and number of cycles to get to release quality.
At any given point in OPNFV release cycle we can expect to combine a number of different layers source module and resulting artifacts to provide the OPNFV value add. 1. Stable branches and artifacts from upstream projects 2. Transient patches, which will move to the upstream project at a convenient time 3. OPNFV native projects which will continue to live in the OPNFV repo and be built as value add on top of upstream projects. Functionality and logic will move between 1 and 2 but should be transparent to the function of the resulting artifacts.
The Project Lead is expected to be responsible for the the project meeting deadlines, interacting with other projects, and interacting with the TSC The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion, i.e., 48 hours excluding weekends
Milestones, Release Candidates, and Service Releases[edit] • Milestones are spaced roughly 4 weeks apart taking into account significant holidays. • Release Candidates (RC) are spaced 2 weeks apart • Service Releases are roughly 6 weeks and 12 weeks after the Formal OPNFV Release.