ah missed that. I still think this is overly complicated. We still need to run CI before we release. So what does this buy us?
On Thu, May 7, 2015 at 9:24 AM, Aleksey Yeschenko <alek...@apache.org> 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. > > 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 -- http://twitter.com/tjake
