Page History

...

Spec - a detailed level design design of a change that is planned but focused on a single component. Has to be approved by impacted project Team. Just technical details, no resource allocation.

Best ONAP best practice - "codding coding standard" (may be code related, security related, configuration related etc.) recognized by the community that should be followed. Approved by TSC, has to be followed by any new code entering the tree. Enforced for a code arriving for a review after approval.

Global requirement - best practice, non functional requirement chosen by the TSC to be applied to whole ONAP code base during a given release. Enforced since beginning of release X for whole ONAP code base. Stays forever

Assumptions

1. DON'T BREAK ANY THE MASTER!
2. All approved best practices are checked in gerrit review and enforce for any new code that is entering the tree
3. Global requirements are mandatory for all projects. If project fails to deliver global requirements, it is descoped from the release (previous release containers are used).
4. TSC defines the vision and sets the direction for ONAP project
5. Based on recommendations from subcommittees, TSC makes the final decision whether the new feature should be approved or not.
6. TSC makes the final decision whether the best practice should be approved or not.
7. Architecture team consists of best ONAP specialists ONAP specialists (both on functional and implementation view) that can clearly asses assess whether the proposed feature is aligned with long term ONAP vision and is aligned with ONAP design principles
8. Security Team consists of best ONAP security specialists that can clearly asses assess whether the proposed feature does not compromise ONAP security standards
9. All other subcommittees consists of ONAP specialists in a given domain who help to asses the proposal if it touches their domain of interest
10. Anyone is free to propose a new feature into ONAP at any point of the time but it has to be scoped to the release before the deadline in order to be considered as active
11. Anyone is free to asses assess the proposed feature form from a technical point of viewBased on recommendations from subcommittees TSC makes the final decision whether the new feature should be approved or not.
12. Anyone is free to propose new best practice
13. TSC makes the final decision whether the new feature should be approved or not.
14. All approved best practices are checked in gerrit review and enforce for any new code that is entering the tree
15. Global requirements are mandatory for all projects. If project fails to deliver global requirements it is descoped from the release (previous release containers are used).
16. at any point of time
17. Before project meets all global requirements for a given release, it cannot make backward incompatible changes that are impacting other components.
18. Project may release a new docker image at any point of the release (taken into account previous point)
19. PTL is free to define additional rules and quality metrics that has to be met before the patch can be merged
20. Anyone is free to submit any patch at any point of the time
21. It's PTL & committers responsibility to make sure that patches they merge for a given branch obey to the rules set by TSC (best practices, release phase)
22. PTL and committers are responsible for the project condition
23. PTL and committers have a full control over what and when should be merged (ie. They can prevent functional patches from being merged until global requirements for their project are met

Proposal

1. )
2. It's up to the feature/spec owner to organize resources to implement it.
3. Features can be worked on since approval until they are ready, no matter if it takes a release of 5 years. The release is always on time just like a train, always on time. You missed one, no issues, you can release new docker as a part of the next release as soon as you are ready
4. Main requirements artifacts are: Specifications, Features and Global Requirements
5. Split  the set of work items into Global Requirements set by the TSC and Specifications and Features from the projects and use case teams that are set by the working teams.
6. Global Requirements are created and managed by the TSC
7. Specirfications and Features are created and managed by the working team , including cross project commitments.
8. Global Requirements are specific to a release.
9. Specifications and Features can span releases and can scheduled to be "available" once all items are complete and tested. This is the part that is "getting on the train" and can be flexibly scheduled.

Development

• Keep 3 releases in a year:
  • W8
  • W24
  • W43
• Divide the release in 3 sections:
  • R - 16 Release kickoff  (example April October 2020 for Guillan Honolulu right after Frankfurt Guilin signoff)
    
    • Start estimating which global requirements can be met in this release (security metrics, python upgrade, infra etc)
    • Start socializing global requirements proposals with PTLs so that every one knows what should has to be done
    • Ideas for global requirements should be provided before the kickoff, this time slot is only for choosing ideas for this release
    • in this release
    • Features and specs Project/Use Case requirements work is ongoing during this phase as well.
  • R - 14 Global requirements defined
    • TSC approves a list of global requirements that has to be address by the teams in this release
  • R - 10 Spec freeze   (example August December 2020 for GuillanHonolulu)
    
    • All features and specs that are going to be implemented in this release should be approved (Global and Specification and Features from Project/Use Caseand marked as active
    • At this point we know what we will get in this release (at most)
  • R - 5 Feature freeze  (example September 2020 February 2021 for GuillanHonolulu)
    
    • End of accepting patches containing new features for this release
    • Start of bug fixing period
    • Release branch is being created for all participating projects
      
      • particularly OOM so that we can start to focus on the release package of helm charts and corresponding docker containers
  • R - 3 Beginning of RC-phase (example October February 2020 for GuillanHonolulu)
    
    • RC every end of week
    • Bug fixes submitted for both master and release branch
    • Feature development may continue for approved specs in the master branch
  • R - 0 - final testing, release notes and Sign-off  (example October March 2020 for GuillanHonolulu)
  • R - 16 of next release (example November 2020 for H release)
  Assumptions:
  • Architecture (spec) work is being done continuously
• Every spec has below stages in its life cycle:
  • Proposed
    • The spec has been proposed by the author for a review by affected parties
  • Approved
    • The spec has been reviewed by interested parties and approved
    • In this point we agree that the design is good and if agreed we find the resources so it can be implemented
  • Scoped for the release
    • There is a volunteer to work on this particular spec within this release
    • The work may be continued in next release with PTL and TSC consent.
  • Implemented
    • The spec has been fully implemented and should be mentioned in the release notes
  • Dropped
    • The spec has been dropped because no one is willing to work on it or it became out of the date

Glossary

global requirements - must have requirements for projects like security, python upgrade etc

Calendar

As Frankfurt is going to be release on 23rd of April we need to adjust our release schedule for next year. I propose to extend the G release and start it on 30th of April and have Sign-off on 22nd of October. After that we would continue as defined in the proposal.

Recording from 08.07.2020:

Image Removed

Please move the calendar to March to see the impact of our proposal on the release cycle.

...