Scenario Owner

A scenario owner is the individual that takes responsibility for ensuring that a scenario meets all milestone requirements and is successfully released, per the release schedule. Every scenario must have a scenario owner. Note that the scenario owner is often the same person as the PTL for the feature that is deployed by the scenario.

The scenario owner works with installer owners, test framework owners, and feature project teams to setup Jenkins jobs, fix build issues, enable testing, and resolve bugs and document the scenario. Note that it is NOT the responsibility of installer teams or test framework teams to integrate scenarios, fix build issues, or fix bugs. These teams may provide support for these activities when requested by the scenario owner, however, it is ultimately up to the scenario owner to ensure that the scenario is ready for release.

Requirements for Participation

Planning

Projects must submit a proposal and be approved by the TSC before they may join a release.

Note that infrastructure projects, including RELENG, OPNFVDOCS and Pharos are presumed to be participating and are not required to submit intent-to-participate.

Projects must develop and post a release plan by MS1. The content and format of the release plan is the decision of the PTL and project team. However, fell free to use this suggested template, if you'd like.

OpenStack Version

Prior to each release cycle the TSC approves a milestone schedule and the version of OpenStack that will be used by projects and scenarios that have OpenStack dependence (most). For the Iruya release, the TSC approved the selection of OpenStack TBD. Therefore, all OPNFV project participating in the release will use this version of OpenStack.

Milestone Compliance

Projects must adhere to the milestone requirements, according to the schedule approved by the TSC, unless they have an approved milestone exception.

Milestone compliance will be evaluated by the Release Manager and results will be published on the Milestone Compliance page.

Continuous Integration

Projects delivering software for an OPNFV release must be integrated with OPNFV CI, including builds (MS5) and automated testing (MS6).

DO NOT leave the "fix version" field at "None". This creates confusion about the workload for a particular release, since it's unclear which release the project intends to work on a particular release. If you are unclear about when an issue will be resolved, then assign the issue to a valid future release, or to the release named "Future Release".

DO NOT make up your own version names. Valid version names have already been added to the projects. If your JIRA project does not contain these version names, you may add them yourself, or contact the release manager.

Valid release names for the Iruya release, are as follows:

8.0.0, 8.1.0, 8.2.0

Future Release

Note: use this string if you don't anticipate resolving the issue in the current release. However, this means that you should periodically review issues assigned to "Future Release" and reassign them to a specific release.

In order to support the use of JIRA for program management and for data collection (e.g., Bitergia), projects must do housekeeping on their JIRA project

Keep the status updated.

Close issues that have been verified resolved, or that are no longer relevant.

Update the "fix version" field for issues that you plan to defer to a future release. We should not have unresolved issues that are assigned to past releases.

Update the "Assignee" field as people leave and join the project.

Documentation

Documentation compliance is checked at MS4 (preliminary) and MS7 (final). Projects indicate their compliance by completing the documentation compliance tables for MS4 and MS7.

Content

Projects are free to determine what documentation is appropriate for their project. However, the following documents are suggested for various project types:

Known issues documented in JIRA and published in documentation for any failing tests.

Installer Projects

Meets the requirements of all applicable milestones, especially MS3 and MS9.

Tool and Test Framework Projects

Meets the requirements of all applicable milestones, especially MS4 and MS9.

Passes self-validation tests.

Schedule

Milestone Gantt Chart

The Gantt chart view (see "Gantt Chart" in Important Links) is useful for seeing an overview of the schedule, including related events (e.g. upstream component releases, community events. plugfests, etc.).

Milestone Schedule and Events

The deadline time for all milestones is 5 p.m. Pacific Time, unless otherwise stated.