An update on issue states and merge procedures
Alex Mineer
tl;dr:
"Fixed" issue status now indicates fixed on main; most bugs should be marked fixed before requesting a merge
Use Chromium Dash's updated Branches page to understand which branches are active and what merges are eligible
We've refreshed our merge process documentation here to account for the above changes and to consolidate documentation
Labels to track potentially missed merges are changing; Merge-TBD will become Merge-TBD-##, and we'll use Merge-NA-## to label issues where a merge isn't required for a given milestone
Hey everyone,
We're making a handful of updates around issue statuses and our merge process; we're hopeful that these changes help clear up some common sources of confusion and make it easier for you to work with our release branches.
"Fixed" now means "fixed on main"; most issues should be marked "Fixed" prior to merging
We're updating the definition of our issue statuses in crbug/ to indicate that "Fixed" means the issue is addressed on main; as a result, unless you are merging diagnostic code to a release branch, all issues should be marked "Fixed" ahead of requesting a merge. This change will ensure that our release automation (like Sheriffbot) will be able to properly evaluate high impact issues and flag where merges might be required just in case a developer has forgotten about an active release branch. As part of this change, we'll also be updating the descriptive text for the "Verified" status as well, and you can see both changes below:
Previous status descriptions:
Fixed: Work completed, needs verification
Verified: Test or reporter verified that the fix worked
New status descriptions:
Fixed: Work completed on main, needs verification and merges (if applicable)
Verified: Test or reporter verified that the fix worked on all applicable branches
Use Chromium Dash's Branches page to learn which branches are active and what merges are acceptable
We know it can be painful and error-prone for developers to manually look up what branches are currently active, and what types of merges are acceptable - and that the situation will get more complex with the upcoming launch of the Extended Stable channel. To help make everyone's lives easier, we've updated Chromium Dash's Branches page to list explicitly what branches are active and what merges are acceptable based on where each branch is in its respective release cycle. We hope this helps, but if you have feedback on this new page (or Chromium Dash in general) please leave it here.
We've updated our merge documentation and added tools to help track your potential merges
To account for both changes above, we have refreshed our merge process documentation here. As part of this change, we've also consolidated several pre-existing pages into this new holistic page (e.g. instructions for how to process a merge now live alongside the merge process docs themselves). We've also added instructions on how to use new project queries in crbug/ to keep an eye on your merges; you can learn more about those here.
Merge-TBD will become Merge-TBD-##
Last but not least, we've also modified one of our intermediate merge process states, Merge-TBD; this label used to be applied when automation detected that a merge might be required to any release branch, but it was not milestone-specific and our prior process (simply removing Merge-TBD if inapplicable) led to a flaky Sheriffbot implementation and missed merges. To solve both issues, we'll now add a milestone number to each Merge-TBD label (e.g. Merge-TBD-93) and we'll ask developers to replace that with either a merge request or by indicating that the merge is not applicable to that milestone with a new label set, Merge-NA (e.g. Merge-NA-93).
We believe all of the above will help improve Chromium's merge request and review processes, but please reach out with any questions or concerns.
Cheers,
Alex