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 <https://github.com/fastmail/mint-tag>. You might
also find this tool useful for building your own test Cyruses.
--
rjbs
