Page Comparison

...

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

...

• Keep 3 releases in a year:
  • W8
  • W24
  • W43
• Divide the release in 3 sections:
  • R - 16 Release kickoff  (example October 2020 for Honolulu right after Guilin signoff)
    
    • Start estimating which global requirements can be met in this release
    • Start socializing global requirements proposals with PTLs so that every one knows what has to be done in this release
    • Features and specs 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 December 2020 for Honolulu)
    
    • All features and specs that are going to be implemented in this release should be approved and marked as active
    • At this point we know what we will get in this release (at most)
  • R - 5 Feature freeze  (example February 2021 for Honolulu)
    
    • 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 February 2020 for Honolulu)
    
    • 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 March 2020 for Honolulu)
  • R - 16 of next release (example November 2020 for H release)
• 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

Recording from 08.07.2020:

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

...