Pull requests for delivery - NetBeans (original) (raw)

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.
• We aim to create release candidates on a weekly basis. Please keep this schedule in mind, as well as the time needed to pass tests and review, when targeting delivery.
• 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 weeks of testing and 3 release candidates for each release. A release candidate may be skipped if there are minimal changes in delivery that week. A decision on further release candidates is usually based on the existence of high/critical priority issues or pull requests.
• Nothing is merged between last release candidate and vote (they are built from the same commit). Each release candidate adds about a week to the release timetable. We can sometimes shorten this where changes are limited in scope.
• 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).

Notes on retargeting existing pull requests from master to delivery (or vice versa):

• Committers should not change the PR target branch without leaving a comment. Changing the target will require to rebase the branch, a fresh CI run and renewed reviewer approval.
• Please renew the review requests if the PR target is modified.