> If one of them breaks, we go and edit the _staging branch in place to correct > the problem, and let CI run again.
I would strongly advise against *in place* edits. If we do it, we'll end up in weird situations which will be annoying for everyone. Editing commits that have been shared is almost always a bad idea and that's especially true for branch that will have some amount of concurrency like those staging branches. Even if such problems are rare, better to avoid them in the first place by simply commit new "fixup" commits as we currently do. Granted this give you a slightly less clean history but to the best of my knowledge, this hasn't been a pain point so far. > 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 If we do this, we should really automate that last part (have the CI environment merge the staging branch to the non-staging ones on success). > It seems if we want an "always releasable" set of branches, we need something > along these lines. Agreed as far as having staging branches vetoed by CI goes. Less sure about the edit-commit-in-place part as said above. > I certainly break tests by mistake, or the build itself, with alarming regularity. I agree running tests is painful, but at least for the build, this should be the responsibility of the committer to build before merging. We all forget it from times to times and that's ok, but it's not ok if it's "alarmingly regular". -- Sylvain
