master branch: merging less

Ricardo Signes rjbs at
Thu May 28 09:35:58 EDT 2020

Cyrus developers,

Right now, the policy on what goes in master is "when a committer thinks it's ready for master, it goes in master." This hasn't been a serious problem, but we can do better. What I'd like to do is have feature branches live longer *as* branches, and then be merged when we think they're done. This will make it easier to declare that a feature is really in Cyrus (even if it's only in a 3.${odd} release), and to produce builds with features turned off and on. It will also make it easy to drop an experiment without scouring history much. Finally, it should make code review better, as it can be part of the "can we merge this?" process and when it happens, the whole feature changeset can be seen at once.

There isn't much actual policy change to talk about. Something like this:

> Changes to Cyrus are made in branches. Branches aren't merged until the feature seems plausibly done. When a feature is still undergoing testing, it's left in a branch. Pull requests are opened on GitHub, and before the branch is merged, code review is completed by another committer to the one who wrote the change. Branches should, whenever practical, be rebased before merging. Trivial bugfixes and changes to documentation may be applied directly to master, but when in doubt, favor making a branch!

This will go somewhere in our "Contribute code and tests" section, but right now there seems to be no discussion of policy after the creation of a PR.

At present, Fastmail tends to run very close to master, and we're often testing features before they're in a state we'd consider mergeable under this policy. To make it easy to build a Cyrus that includes all the latest bugfixes and approved experimental branches, we built a tool to merge all the pull requests we've flagged for inclusion <>. You might also find this tool useful for building your own test Cyruses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Cyrus-devel mailing list