Release Engineering Process and Merge Queue Management

All PRs open for consideration to be merged are listed on https://merge-list.zephyrproject.io/. The criteria for merging include:

• The PR must be listed.
• The PR listing must not be grayed out.
• The PR listing must be bold.

Please note exceptions to the requirements are kept very minimal. If in doubt about a PR, please ask on Discord channel #release.

Merging PRs is typically done in batches. A merge batch is initiated by a single person with the expectation to go through all ready to merge PRs, conduct a final quick review, and merge if no issues were identified. Examples of when a merge would be delayed or needs further actions include:

• Identified wrong assignee.
  • ACTION: The PR should be re-assigned.
• Large changes with minimal reviews. For example, many areas being changed.
  • ACTION: add more people as reviewers, ping additional reviewers.
• CI was last run a long time ago, typically measured as 3-4 weeks.
  • ACTION: re-run CI (or close/open PR if last CI run is so old GitHub doesn't let you re-trigger)
• This is usually the case for PRs that fall under the 4 eyes rule.
• In general, PRs should not be cherry-picked, the queue needs to be processed in full.

When starting a merge batch, there are a few best practices to follow designed to minimize disruption to the CI and contributors.

• The CI must not be in a broken state, as denoted by a red X on the merge-list page.
  • Merging of a hotfix to correct CI is an exception.
  • Merging of a revert to correct CI is an exception.
• The CI should be in a completed state (see exceptions above), as denoted by a red X or green check on the merge-list page.
  • Disrupting a CI job can impact the ability to get a clean status on the main branch.
  • A typical merge batch CI run to completion can range between 2 hours and 5-6 hours depending on the time of the day.
• Outstanding hotfixes should be prioritized first.
• PRs should be merged from oldest (lowest) to most recent (top of page) to minimize rebase conflicts

The individual starting a merge batch is responsible to followup on issues that might arise. For example, if a merged PR is causing CI failures, authors of the PR need to be notified and an issue should be created where it makes sense. If the problem can be solved with a hotfix, a PR should be submitted to fix the problem. When CI is broken with new issues that are still being investigated, no further PRs shall be merged. In cases where the issue is causing failures across the tree with no immediate fix in sight, a revert of the offending PR should be considered.