Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Subject: Re: Branching master
To: dev@asterixdb.incubator.apache.org
References: 
 <CAHWyyRyq3i=bV-T_um8gcn2H3Wks2aTWJrSzZmc_xrv8rQBDsQ@mail.gmail.com>
 <CAHWyyRx5HrG3toneSg9VArAsM-Rez1RfJ09ObhUwgeZxi2ZS4w@mail.gmail.com>
 <CAHWyyRzfTo7_dsKNDsPgybSfbL6O+oHTHqaTkxex4xHYVBwQRw@mail.gmail.com>
 <CAHWyyRzi1XQC69BjroYkN2V1QfuyLmXF76CZbn+uMDtRsGB4GQ@mail.gmail.com>
 <CAHWyyRwNFU19XBwO0LOQoj60Zy=Og6eOvtOT-cgakLMyCOggEw@mail.gmail.com>
 <CAHWyyRxivCSB=u06EdPXF87FY_uqnVwBMaKEg-MHygRmy9yR_A@mail.gmail.com>
 <CAHWyyRy=F=-d4pfkfj_1ejvXHf-wxXWZzLQ4c6f28tZoNYYOng@mail.gmail.com>
 <CAHWyyRz+QqAgtdk-c7d7o9zP3oO2Yz-5a_Lqg20Z9U4ZMgVmsA@mail.gmail.com>
 <62549E95-86EB-41FE-BD53-70488B999A0F@apache.org>
 <CAN_YF5yHLY7=01EH4XZE7X90YAJp7d0x2TjghS1nEQ6sRFnOqA@mail.gmail.com>
 <227F9E98-022D-45DC-B117-AF9F472E2170@apache.org>
From: Mike Carey <dtabass@gmail.com>
Message-ID: <560A0FE0.20108@gmail.com>
Date: Mon, 28 Sep 2015 21:13:20 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <227F9E98-022D-45DC-B117-AF9F472E2170@apache.org>
Content-Type: multipart/alternative;
 boundary="------------050002020904080004060909"

--------------050002020904080004060909
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

+1

On 9/28/15 11:20 AM, Till Westmann wrote:
> I think that we should aim to never need to pick from master to 
> release, only from release to master.
> The release branch gets all the release fixes and those are merged 
> into master more or less immediately.
> And development continues on master and everybody developing off 
> master needs to merge the current master (that includes the release 
> fixes) into their work.
> This is at least how I’ve seen this handled in the past or revision 
> control systems that were much worse at merging that git …
>
> Cheers,
> Till
>
> On 28 Sep 2015, at 11:03, Ian Maxon wrote:
>
>> Gerrit can totally handle more than one branch. Having a branch in the
>> ASF repo, likewise, is a near zero overhead operation.
>> I've had similar thoughts about this, and I know it's not without
>> precedent, so the idea is definitely +1 from me.
>>
>> I think the only sticky part could possibly be merge vs. rebase.
>> Imagine if a change needs to be picked from the master to release
>> branch, but not some of its predecessor commits. The commit itself
>> would have to change despite having (likely/hopefully) semantically
>> equivalent content, and I think that could get very messy (similar
>> issue to the squashed feature branch discussion).
>>
>> -Ian
>>
>> On Mon, Sep 28, 2015 at 9:29 AM, Till Westmann <tillw@apache.org> wrote:
>>> I think that a release-branch sounds like a good idea. The question 
>>> is, how
>>> we manage the code/review flow. To be able to review the changes the 
>>> should
>>> go into the release in the usual way, I think that we’d need to have 
>>> Gerrit
>>> know about more than one branch. Not sure how easy/difficult that 
>>> is. Also,
>>> the release branch obviously would need to be in the ASF git repo.
>>> How much effort do you think this would be (infrastructure-wise)?
>>>
>>> Cheers,
>>> Till
>>>
>>>
>>> On 27 Sep 2015, at 23:31, Chris Hillery wrote:
>>>
>>>> There are a lot of changes that are stacking up in Asterix because 
>>>> we're
>>>> trying to get a release done. I'm thinking it might be a good 
>>>> exercise and
>>>> preparation for next time if we branched Asterix master for the 
>>>> release
>>>> and
>>>> started allowing changes to be merged that are for post-release, 
>>>> instead
>>>> of
>>>> basically having a code freeze which has been going on for, what, 
>>>> several
>>>> months already?
>>>>
>>>> We could either create a release branch off master and do the 
>>>> necessary
>>>> release cleanup over there, or else create a "develop" branch from 
>>>> master
>>>> and start committing new changes there. Branching a release branch off
>>>> master probably would require fewer changes to our existing
>>>> infrastructure.
>>>> Either way, once the release was complete, we'd merge the branch 
>>>> back onto
>>>> master and continue.
>>>>
>>>> Anyone say yay or nay?
>>>>
>>>> Ceej


--------------050002020904080004060909--