Release Cadence Proposal

This is just a draft version put together to capture the feedback provided during the meeting and present my point of view based on my experience in other open source projects

Current state

• Patches are submitted via gerrit
• Architecture is described on a wiki and (sometimes) later migrated to read the docs
• We have a waterfall-ish development model with clearly distinguish planning, designing, implementation and testing phases
• There is a lot of paper work to be done at every milestone
• Features for every release are described globally (per release) and approved by TSC in the beginning of each release
• We have 2-3 releases per year

Proposal

Main requirements artifacts are: Specifications, Features and Global Requirements

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.

Global Requirements are created and managed by the TSC

Specirfications and Features are created and managed by the working team , including cross project commitments.

Global Requirements are specific to a release.

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 2020 for Guillan after Frankfurt signoff)
    
    • Start estimating which global requirements can be met in this release (security metrics, python upgrade, infra etc)
    • Start socializing global requirements with PTLs so that every one knows what should be done
    • Ideas for global requirements should be provided before the kickoff, this time slot is only for choosing ideas for this release
    • 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 2020 for Guillan)
    
    • All features that are going to be implemented in this release should be approved (Global and Specification and Features from Project/Use Case)
  • R - 5 Feature freeze  (example September 2020 for Guillan)
    
    • 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 2020 for Guillan)
    
    • 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 2020 for Guillan)
  • 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 we find the resources 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.

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