"Our process is our own" <- always remember this.
> On May 7, 2015, at 9:25 AM, Ariel Weisberg <ariel.weisb...@datastax.com>
> wrote:
>
> Hi,
>
> Whoah. Our process is our own. We don't have to subscribe to any cargo cult
> book buying seminar giving process.
>
> And whatever we do we can iterate and change until it works for us and
> solves the problems we want solved.
>
> Ariel
>
> 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.
>>>
>>
