+1. I would ask that if we end up doing this that it be documented on the wiki.
Gary. On Thu, May 7, 2015 at 4:05 AM, Benedict Elliott Smith < belliottsm...@datastax.com> wrote: > 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. >
