Commit Management

Because CI takes so long, we use a token-passing scheme to coordinate landing commits on trunk. We want to avoid changing trunk at a surprising time, invalidating the next person's CI run,

Previously, we used the keybase #engineering channel to coordinate this. The practice was to change the "headline" (topic) of the channel to Q:[name1, name2] to establish a queue of people allowed to land. Sometime we used Q:[name1#PRnum, ..] to make it more explicit (also giving name2 implicit permission to claim the token if the given PR had already landed, usually done in conjunction with GitHub's auto-merge setting).

Mergify instructions

We're experimenting with https://mergify.io now (@michaelfig is driving).

For repositories that have opted into the Mergify queue management, you can add an automerge:<method> GitHub label (in the Labels section to the right of the PR conversation) to a PR to have it queued for landing on trunk. This is a more powerful replacement for hitting the Automerge button on GitHub, which will help replace the manual rebasing process.

If you'd like, you can see the current merge queue at https://dashboard.mergify.io

Protobuf / Breakage

One of our CI tests verifies that there have been no breaking changes in the Protobuf .proto files. If you have made a breaking change but still want the PR to be merged, add a proto:expect-breakage label to it, in addition to the above automerge:... label. Then Mergify will only land the PR if there was a breaking proto change. If there really wasn't a breaking change, remove the proto:expect-breakage label; you don't need it.