Strictly speaking, the train schedule does demand that trunk, and all other branches, must be releasable at all times, whether you like it or not (for the record - I *don’t* like it, but here we are).
This, and other annoying things, is what be subscribed to tick-tock vs. supported branches experiment. > We still need to run CI before we release. So what does this buy us? Ideally (eventually?) we won’t have to run CI, including duration tests, before we release, because we’ll never merge anything that hadn’t passed the full suit, including duration tests. That said, perhaps it’s too much change at once. We still have missing pieces of infrastructure, and TE is busy with what’s already back-logged. So let’s revisit this proposal in a few months, closer to 3.1 or 3.2, maybe? -- AY On May 7, 2015 at 16:56:07, Ariel Weisberg (ariel.weisb...@datastax.com) wrote: Hi, I don't think this is necessary. If you merge with trunk, test, and someone gets in a head of you just merge up and push to trunk anyways. Most of the time the changes the other person made will be unrelated and they will compose fine. If you actually conflict then yeah you test again but this doesn't happen often. The goal isn't to have trunk passing every single time it's to have it pass almost all the time so the test history means something and when it fails it fails because it's broken by the latest merge. At this size I don't see the need for a staging branch to prevent trunk from ever breaking. There is a size where it would be helpful I just don't think we are there yet. Ariel 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. >
