I'm not sure how I feel about this, on the one hand cleaner trunk is good, on the other, added complexity leaves more room for error. I'm +0 currently.
> 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? Apart from the auto-committing CI bot suggestion, this proposal is just a handful of new branches to test. We can add that to CassCI today, no problem. On Thu, May 7, 2015 at 10:13 AM, Aleksey Yeschenko <alek...@apache.org> wrote: > 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. > > >
