...
- 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 what we can do within the release
- Start socializing global requirements (for example S3P)
- 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 by Arch and impacted PTLs
- 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 (1
- RC every
- end of week
- Bugfixes 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
- R - 16 Release kickoff