Branches and Commits and Cherry-Picking

[Alex Harui <ah...@adobe.com.INVALID>]

Hi,

I think we may need to be more careful about branches and commits in the future.  I saw a fair number of merge conflicts for the RM to have to resolve to merge the release branch back into develop.  The use of cherry-picking may be part of the problem.  I wrote down my thoughts on the subject in the wiki https://github.com/apache/royale-asjs/wiki/Branch-Management

Now it is true that in the future, the release branches may not live as long so there will be fewer conflicts, but if we are successful and become a more active community, we will want to have good practices around this so that the develop branch can handle less stable commits while were getting a release out.

My takeaway is that cherry-picking is not a best practice http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html because the changes in each branch are not correlated.

Let's discuss,
-Alex

Re: Branches and Commits and Cherry-Picking

[Carlos Rovira <ca...@apache.org>]

HI Alex,

right, I'm only saying that as part as the natural process, people should
not need to ask for agreement, since what is in develop should not go to
release. And if something need to be fixed in release it will happen there
(of course promoted by some discussion about something is not working
there), and that will, in the end merged back ro develop and master when
release is done. Otherwise means people in team are not applying the before
mentioned git branch model article.

Thanks





El dom., 6 oct. 2019 a las 0:40, Alex Harui (<ah...@adobe.com.invalid>)
escribió:

>
>
> On 10/5/19, 7:08 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
>     Hi Alex,
>
>     - release: Here's where I see differences. Once we decided we want to
>     release, is because develop has the final state to cut a release. No
> more
>     commits are needed for that release. So once a RM start the process and
>     creates release branch from develop, then no more things should go to
>     release branch. NOW: If we have to fix something for release, this is
> done
>     in release and then "merged" (not cherry-picked) to develop at any
> time.
>     Finally as we get to the final process, release is merged in master and
>     develop.
>
>     Notice that in parallel: develop can continue to evolve, but that will
> not
>     go into that current release, will go to the next.
>
>     As well, I think Cherry pick can be an option for many other use
> cases. Is
>     like using rebase, those are very powerful tools to use when needed.
> Just
>     we all need to know when is the right way to use it.
>
>     I think the problem right now is that when we start the release, we
>     continue with open mind to add all we do in develop. This is due to our
>     current release process getting to long in time. I think next release
>     process should be very less time and will be less new things in
> develop so
>     what we have in release will be what we really release, instead of
> continue
>     adding new develop things.
>
>
> IMO, because we don't have dedicated testing, we are going to find
> important things when we start testing the release branch.  So it isn’t "if
> we have to fix something for release" it is "when we have to fix something
> for release" and I am asking the other committers to be more careful in the
> next release and not just commit stuff to develop.  Be aware if a release
> is in progress and get agreement to push your fix to the release branch.
>
> I sure hope the release branch is open only for a much shorter time, but
> I'm also sure we will find something to fix in almost every release.
>
> -Alex
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Branches and Commits and Cherry-Picking

[Alex Harui <ah...@adobe.com.INVALID>]

On 10/5/19, 7:08 AM, "Carlos Rovira" <ca...@apache.org> wrote:

    Hi Alex,
    
    - release: Here's where I see differences. Once we decided we want to
    release, is because develop has the final state to cut a release. No more
    commits are needed for that release. So once a RM start the process and
    creates release branch from develop, then no more things should go to
    release branch. NOW: If we have to fix something for release, this is done
    in release and then "merged" (not cherry-picked) to develop at any time.
    Finally as we get to the final process, release is merged in master and
    develop.
    
    Notice that in parallel: develop can continue to evolve, but that will not
    go into that current release, will go to the next.
    
    As well, I think Cherry pick can be an option for many other use cases. Is
    like using rebase, those are very powerful tools to use when needed. Just
    we all need to know when is the right way to use it.
    
    I think the problem right now is that when we start the release, we
    continue with open mind to add all we do in develop. This is due to our
    current release process getting to long in time. I think next release
    process should be very less time and will be less new things in develop so
    what we have in release will be what we really release, instead of continue
    adding new develop things.
    
    
IMO, because we don't have dedicated testing, we are going to find important things when we start testing the release branch.  So it isn’t "if we have to fix something for release" it is "when we have to fix something for release" and I am asking the other committers to be more careful in the next release and not just commit stuff to develop.  Be aware if a release is in progress and get agreement to push your fix to the release branch.

I sure hope the release branch is open only for a much shorter time, but I'm also sure we will find something to fix in almost every release.

-Alex 

Re: Branches and Commits and Cherry-Picking

[Carlos Rovira <ca...@apache.org>]

Hi Alex,

I'm with the article exposed in [1], I think I'm using it since 2010.

But I think we have a different interpretation of a release branch. For
what I saw for almost 10 years using git is that we have:
- master: Is the "stable" branch with "released" content. So latest release
can be found at master
- develop: Is what we use to develop incrementally. If we need to fix a bug
or add an enhancement, we do here. develop must be always stable, so if a
fix is just one commit, we can do this directly on develop, but if more
work needs to be done, and more than one commit is needed to be stable
again, then we need to create a feature branch.
- feature: changes that need more than 1 commit to be stable. Do all
commits in this kind of branch, and finally merge in develop when finished.
Then this branch can be removed.
- release: Here's where I see differences. Once we decided we want to
release, is because develop has the final state to cut a release. No more
commits are needed for that release. So once a RM start the process and
creates release branch from develop, then no more things should go to
release branch. NOW: If we have to fix something for release, this is done
in release and then "merged" (not cherry-picked) to develop at any time.
Finally as we get to the final process, release is merged in master and
develop.
- hotfix: we don't use it this for now. I think is normal since we are
still doing very heavy development, but when we get to 1.0 I expect hot
fixes will start to have relevance. IOW, I expect we'll get a time where
releases will be lower since we'll have a very stable tech, so hot fixes
will come to fix concrete bugs discovered in a release that need to be
fixed, and users don't want to enter other kind of evolutions in the SDK.

Notice that in parallel: develop can continue to evolve, but that will not
go into that current release, will go to the next.

As well, I think Cherry pick can be an option for many other use cases. Is
like using rebase, those are very powerful tools to use when needed. Just
we all need to know when is the right way to use it.

I think the problem right now is that when we start the release, we
continue with open mind to add all we do in develop. This is due to our
current release process getting to long in time. I think next release
process should be very less time and will be less new things in develop so
what we have in release will be what we really release, instead of continue
adding new develop things.






[1] https://nvie.com/posts/a-successful-git-branching-model/

El sáb., 5 oct. 2019 a las 2:19, Alex Harui (<ah...@adobe.com.invalid>)
escribió:

> Hi,
>
> I think we may need to be more careful about branches and commits in the
> future.  I saw a fair number of merge conflicts for the RM to have to
> resolve to merge the release branch back into develop.  The use of
> cherry-picking may be part of the problem.  I wrote down my thoughts on the
> subject in the wiki
> https://github.com/apache/royale-asjs/wiki/Branch-Management
>
> Now it is true that in the future, the release branches may not live as
> long so there will be fewer conflicts, but if we are successful and become
> a more active community, we will want to have good practices around this so
> that the develop branch can handle less stable commits while were getting a
> release out.
>
> My takeaway is that cherry-picking is not a best practice
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> because the changes in each branch are not correlated.
>
> Let's discuss,
> -Alex
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira