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

Development

• Keep 3 releases in a year:
  • W8
  • W24
  • W43
• Divide the release in 3 sections:
  • R - 16 Release kickoff
    • 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
  • 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
    • All features that are going to be implemented in this release should be approved
  • R - 5 Feature freeze
    • End of accepting patches containing new features for this release
    • Start of bugfixing period
    • Release branch is being created for all participating projects
  • R - 3 Beginning of RC-phase
    • 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
• 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

Calendar