cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedict Elliott Smith <belliottsm...@datastax.com>
Subject Staging Branches
Date Thu, 07 May 2015 09:05:30 GMT
A good practice as a committer applying a patch is to build and run the
unit tests before updating the main repository, but to do this for every
branch is infeasible and impacts local productivity. Alternatively,
uploading the result to your development tree and waiting a few hours for
CI to validate it is likely to result in a painful cycle of race-to-merge
conflicts, rebasing and waiting again for the tests to run.

So I would like to propose a new strategy: staging branches.

Every major branch would have a parallel branch:

cassandra-2.0 <- cassandra-2.0_staging
cassandra-2.1 <- cassandra-2.1_staging
trunk <- trunk_staging

On commit, the idea would be to perform the normal merge process on the
_staging branches only. CI would then run on every single git ref, and as
these passed we would fast forward the main branch to the latest validated
staging git ref. If one of them breaks, we go and edit the _staging branch
in place to correct the problem, and let CI run again.

So, a commit would look something like:

patch -> cassandra-2.0_staging -> cassandra-2.1_staging -> trunk_staging

wait for CI, see 2.0, 2.1 are fine but trunk is failing, so

git rebase -i trunk_staging <ref~1>
fix the problem
git rebase --continue

wait for CI; all clear

git checkout cassandra-2.0; git merge cassandra-2.0_staging
git checkout cassandra-2.1; git merge cassandra-2.1_staging
git checkout trunk; git merge trunk_staging

This does introduce some extra steps to the merge process, and we will have
branches we edit the history of, but the amount of edited history will be
limited, and this will remain isolated from the main branches. I'm not sure
how averse to this people are. An alternative policy might be to enforce
that we merge locally and push to our development branches then await CI
approval before merging. We might only require this to be repeated if there
was a new merge conflict on final commit that could not automatically be
resolved (although auto-merge can break stuff too).

Thoughts? It seems if we want an "always releasable" set of branches, we
need something along these lines. I certainly break tests by mistake, or
the build itself, with alarming regularity. Fixing with merges leaves a
confusing git history, and leaves the build broken for everyone else in the
meantime, so patches applied after, and development branches based on top,
aren't sure if they broke anything themselves.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message