Branching master

[Chris Hillery <ch...@hillery.land>]

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

Re: Branching master

[Mike Carey <dt...@gmail.com>]

+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 <ti...@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

Re: Branching master

[Till Westmann <ti...@apache.org>]

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 <ti...@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

Re: Branching master

[Ian Maxon <im...@uci.edu>]

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 <ti...@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

Re: Branching master

[Till Westmann <ti...@apache.org>]

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

Re: Branching master

[Murtadha Hubail <hu...@gmail.com>]

A big yay from me as long as this doesn't violate Apache rules, and merging unexpected release blockers between the two branches won't be too much work.

-Murtadha

> On Sep 27, 2015, at 11:31 PM, Chris Hillery <ch...@hillery.land> 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

Re: Branching master

[Chen Li <ch...@gmail.com>]

"Yay" from me.

Chen

On Mon, Sep 28, 2015 at 6:43 AM, Mike Carey <dt...@gmail.com> wrote:

> This does indeed seem like a good exercise for future operations - but -
> way too easy for me to say....  :-)
>
>
> On 9/27/15 11:31 PM, 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
>>
>>
>

Re: Branching master

[Mike Carey <dt...@gmail.com>]

This does indeed seem like a good exercise for future operations - but - 
way too easy for me to say....  :-)

On 9/27/15 11:31 PM, 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
>