THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- 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 PR 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 PR pull request with high/critical priority, but . For a pull request the author is often the best person to make that call.
priority:high
means you think the PR pull request is important and should, if at all possible, be included in the release.priority:critical
means you think the PR 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 PRpull 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 PR pull request against delivery after the last scheduled release candidate and label it with
priority:high
orpriority: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).