ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Cole <nc...@hortonworks.com>
Subject Re: [DISCUSS] Future code review and commit process
Date Thu, 04 Jan 2018 16:45:40 GMT
Please also clarify the following scenario:

I’m working on a fix for branch-2.6, and when I’m done, I need to merge to trunk.

What is the flow?
- Create a fork
- Commit to branch-2.6 (on my fork)
- Commit to trunk (on my fork)
- Create pull request to bring changes to both branches?
Or
- Create a fork
- Commit to branch-2.6 (on my fork)
- Create pull request
- Commit to trunk (on my fork)
- Create pull request

This is exposing my git n00bness





On 1/4/18, 11:32 AM, "Attila Doroszlai" <adoroszlai@hortonworks.com> wrote:

    >  *   Since this new flow model requires a branch for a commit, we should enforce
a naming strategy. These short-lived feature branches for commits must be easy to find and
remove. We should also make the community aware that once you have had your pull request merged,
you should get rid of your branch. As for branch naming conventions, I haven't thought through
it very much, but perhaps simply the name of the associated JIRA, such as AMBARI-12345.
    
    Correct me if I'm wrong, but the branch to be merged should be created in your own fork,
not in the apache/ambari repo.  Otherwise non-committers would not be able to create pull
requests.  I think this eliminates the need to coordinate branch naming, although some convention
or pattern would be helpful anyway.
    
    -Attila
    

Mime
View raw message