cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McGuire <r...@datastax.com>
Subject Re: Staging Branches
Date Thu, 07 May 2015 14:23:02 GMT
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 <aleksey@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.weisberg@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 <
> belliottsmith@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message