...
The activities of the ONAP community are articulated around projects and releases. The scope of each project is aligned with the ONAP architecture and the scope of each release is defined with the objective to fulfill a particular requirement(s) (use case(s, functional or non functional).
3.3.1.1. A project is a long term endeavor setup to deliver features across multiple releases, which have a shorter lifespan.
...
3.3.1.3. The key point of the project and release lifecycle process is are to provide adequate visibility to all stakeholders, provide synchronization, and support to all contributors.
3.3.1.4. This document covers the ONAP project lifecycle. The Release Lifecycle is documented in a separate document (include link when ready) Release Process.
3.3.2. Project Lifecycle Overview
3.3.2.1. The project lifecycle provides the freedom for each team to conduct its project according to their needs, culture and work habits. Thus, the project lifecycle is not prescriptive on how each project operates.
...
3.3.2.
...
2.
...
An ONAP release can be composed of 1 to N projects. As such the number of contributing projects to a particular release may vary overtime.
...
3.3.2.
...
3.
...
A release is initiated to deliver a set of project deliverables.
...
3.3.2.
...
4.
...
The project lifecycle process does not impose a duration for the project nor for the release. There is an independent Release Plan document for each release to specify release
...
timelines which includes, but is not limited to the following:
3.3.2.5. Release Plan
3.3.2.5.1. Introduction
3.3.2.5.2. Release Deliverables
3.3.2.5.3. Release Milestones
3.3.2.5.4. Expected Dependencies on Other Projects
3.3.2.5.5. Compatibility with Previous Release
3.3.2.5.6. Themes and Priorities
3.3.2.5.7. Other(s)
3.3.2.5.8. Features delivered
3.3.2.5.9. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.2.5.10. Architectural Issues (if any)
3.3.2.5.11. Security Issues (if any)
3.3.2.5.12. Quality Assurance (test coverage, etc)
3.3.2.5.13. End-of-life (API/Features EOLed in Release)
3.3.2.5.14. Summary of Outstanding Bugs
3.3.2.5.15. Summary of Standards Compliance
3.3.2.5.16. Delta between planned schedule and actual schedule
3.3.2.6. Release Review
The project shall document results of the review in the release notes
3.3.2.6.1. Features delivered
3.3.2.6.2. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.2.6.3. Architectural Issues (if any)
3.3.2.6.4. Security Issues (if any)
3.3.7.6.5. Quality Assurance (test coverage, etc)
3.3.2.6.6. End-of-life (API/Features EOLed in Release)
3.3.2.6.7. Summary of Outstanding Bugs
3.3.2.6.8. Summary of Standards Compliance
3.3.2.6.9. Delta between planned schedule and actual schedule
3.3.3. Project Lifecycle States and Reviews
ONAP project lifecycle defines five six states that each project goes through. The project lifecycle may extend across multiple releases. 3.3.3.1. .
The procedure of moving from one state to the next one is independent from the release and the pace depends on each individual project.
3.3.3.2. In order to effectively review project progress, fivereviews are build-in within the project lifecycle.
3.3.3.3. The lifecycle of a project is depicted on the following diagram:
Project State | Description |
Proposal | Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs. |
Incubation | Project has resources, but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments. |
Mature | Project is fully functioning and stable, has achieved successful releases. It should also be noted that Projects in Mature state meet all Global Requirements. |
Core | Project provides value to and receives interest from a broad audience. It should also be noted that Projects in Mature state meet all Global Requirements. |
Archived | Project can reach the Archived state for multiple reasons. Either the project has successfully been completed and its artifacts provide business values, or the project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review. |
| Unmaintained |
|
...
A project’s release cycle may be tailored by allowing some exceptions to the normal release process. Tailoring may be initiated in two in three ways:
3.3.4.1. By the TSC voting members: TSC voting members reserves the right to allow changes to the process in order to meet criteria that were initially unknown.
...
3.3.4.3. Tailoring practices will be documented as we progress through our releases. The TSC should respond to requests in a timely manner.
3.3.5. Reviews & Metrics Overview
...
3.3.5.2.6. During Release Kick-Off, the project team may request that the TSC conduct a review to move up the ladder.
3.3.6. Project Reviews
...
3.3.6.3.8. Stability, Security, Scalability and Performance levels have reached a high bar and are maintained as such for each release.
3.3.6.4.
...
Termination Review ← Pick up the discussion on the specific wording of "termination" here on
A bounded piece of work is complete, no new features are being added, but there are still individuals around to maintain the code for bug and security fixes.
The goal of the Termination Review is to ensure that:
...
3.3.6.4.3. Project Team has the confidence that its artifacts can be used outside the ONAP community
3.3.6.4.4. Metrics for Termination review are available
...
3.3.6.5. Unmaintained Review
An unmaintained review is automatically triggered when bounded piece of work has had no individuals available or willing to contribute or participate in bug or security fixes in at least two releases.
The goal of the Unmaintained Review is to ensure that:
3.3.6.5.1. Project(s) or sub-project(s) is no more longer part of any official release
3.3.6.5.2. These Project(s) or sub-project(s) are no more subject to longer compliant with non-functional compliances, but are still in OOM.
3.3.6.5.3. The The project will be still part of OOM deployment and High Priority bugs might be fixed bugs might be fixed
The process of managing this review state can be found here
3.3.7. Mature Release Process
A Project’s Committers make all decisions about Releases of that Project. However However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process. The The purpose of the Mature Release Process is to ensure openness and maximum opportunity for participation. The The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle. Towards Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.
Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist the project in coordinating among themselves and the general world in gaining visibility.
These should contain roughly the following sections:
3.3.7.1. Release Plan
3.3.7.1.1. Introduction Introduction
3.3.7.1.2. Release Release Deliverables
3.3.7.1.3. Release Release Milestones
3.3.7.1.4. Expected Expected Dependencies on Other Projects
3.3.7.1.5. Compatibility Compatibility with Previous Release
3.3.7.1.6. Themes Themes and Priorities
3.3.7.1.7. Other Other
3.3.7.1.8. Features Features delivered
3.3.7.1.9. Non Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.7.1.10. Architectural Architectural Issues (if any)
3.3.7.1.11. Security Security Issues (if any)
3.3.7.1.12. Quality Quality Assurance (test coverage, etc etc)
3.3.7.1.13. End End-of-life (API/Features EOLed in Features EOLed in Release)
3.3.7.1.14. Summary Summary of Outstanding Bugs
3.3.7.1.15. Summary Summary of Standards Compliance
3.3.7.1.16. Delta Delta between planned schedule and actual schedule
3.3.7.2. Release Review
3.3.7.2.1. Features Features delivered
3.3.7.2.2. Non Non-Code Aspects (user docs, examples, tutorials, articles articles)\
3.3.7.2.3. Architectural Architectural Issues (if any)
3.3.7.2.4. Security Security Issues (if any)
3.3.7.2.5. Quality Quality Assurance (test coverage, etc etc)
3.3.7.2.6. End End-of-life (API/Features EOLed in Features EOLed in Release)
3.3.7.2.7. Summary Summary of Outstanding Bugs
3.3.7.2.8. Summary Summary of Standards Compliance
3.3.7.2.9. Delta Delta between planned schedule and actual schedule