> The is still the problem of a commit coming into the staging dir after > a previous commit that is being tested. > When the first commit is merged to the stable branch it will include > both tested and untested version.
How so? We’ll only be merging up to the latest tested ref into the stable branch, not all of staging. -- AY On May 7, 2015 at 16:21:54, Jake Luciani (jak...@gmail.com) wrote: The is still the problem of a commit coming into the staging dir after a previous commit that is being tested. When the first commit is merged to the stable branch it will include both tested and untested version. Let's not take releasable branches to literally, we still need to tag and test every "release" if there is a bad merge the CI will catch it just like the in your proposal On Thu, May 7, 2015 at 5: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. -- http://twitter.com/tjake
