Release planning

From OTBWiki
Jump to: navigation, search

Principles of release planning

A release manager is nominated for each release. Nomination is made shortly after previous release announcement. A backup release manager is also nominated, to assist and possibly step in if the official release manager is not available.

The release manager and his/her backup can be a member of the PSC, but also another member of otb-developers list willing to take the spot.

Release manager duty

The release manager is in charge of :

  1.  Listing and tracking all major features proposed for next release (from call for contribution in the early phase and then approved RFCs)
  2. Planing release date and ensures sync with RFCs execution,
  3. Approving feature branch merges
  4. Actually merging feature branches when authors do not have commit rights (github pull request for instance)
  5. Tracking remote module that can be candidate for official inclusion in next release, and ensuring they will be included (see Contributors guidelines)
  6. Submiting the start of the release process to PSC vote
  7. Ensuring proper execution of release process

Remember: all new features must be submitted by RFCs and approved by PSC. Release manager only approves the feature branches merge.

He can also decide to switch a RFC target release if the RFC is not achieved yet, in order to avoid delaying the release.

Feature branch merge acceptance checklist

  1. The feature branch corresponds to an approved RFC
  2. The feature branch is synced with develop
  3. The feature branch is tested on the dashboard (see here) and has no major failure (compilation errors, tremendous amount of warning or failing tests, segfault or not executed tests)
  4. Feature branch author are available during days following the merge to analyse dashboard and fix things in case of unexpected issues after the merge
  5. Release process has not yet started.

It is important to note that a feature branch should be kept relatively small and does not necessarily correspond to the full implementation of a RFC. Small consistent branches implementing parts of RFC can be merged early and get develop closer to the final release state. Further evolutions and implementations of the RFC can be done by continuing the feature branch or opening new branches, and approval of Release Manager should be requested again before merging.

Remote branches deletion

After a feature branch is merged it should be considered "finished" and will be deleted from the remote server. We can of course make exceptions to this if the RFC author asks.