After feature freeze, pull requests for the release should be based on the delivery branch, limited to fixes, and labelled with priority:high or priority:critical if appropriate.

This page clarifies how that works in practice.

The release team handles all merging to delivery. The release team does not control what gets merged. All pull requests for delivery that pass review will be merged for the next release candidate if there is one.

  • When opening a pull request against delivery (or rebasing an existing one), please be explicit about the reason for targeting delivery. That might just be a link to an issue if there is one.
  • Checking suitability of a pull request for delivery should be part of reviewing for everyone, and a reason for requesting changes or vetoing if really necessary.
  • Anyone may label an issue or pull request with high/critical priority. For a pull request the author is often the best person to make that call.
    • priority:high means you think the pull request is important and should, if at all possible, be included in the release.
    • priority:critical means you think the pull request is critical, and the fix must be included in the release.
  • There will usually be a minimum of 3 release candidates for each release. A decision on further release candidates is usually based on the existence of high/critical priority issues or pull requests.
  • Each release candidate adds about a week to the release timetable. We can sometimes shorten this where changes are limited in scope. Nothing is merged between last release candidate and vote (they are built from the same commit).
  • If you open or retarget a pull request against delivery after the last scheduled release candidate and label it with priority:high or priority:critical, you are saying that you believe the release needs to be delayed to get it in; if unlabelled, that it's OK if it doesn't make it in (and it probably won't).
  • No labels