ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vivek Ratnavel <vivekratna...@apache.org>
Subject Re: [DISCUSS] Future code review and commit process
Date Thu, 04 Jan 2018 17:57:40 GMT
Let me clarify a few things here.


   - Before opening any pull requests, one needs to fork
   https://github.com/apache/ambari. This is a one time process.
   - Before working on any JIRA, lets say AMBARI-12345, one needs to create
   a branch from their own fork. Everyone can have their own naming
   conventions to name this branch since this is not going to affect the
   public repository in any way.
   - To answer Nate's question, if a JIRA has to be committed to branch-2.6
   and trunk, one needs to create two branches from their own fork - a branch
   based on branch-2.6 and another branch based on trunk. Let's name them
   AMBARI-12345-branch-2.6 and AMBARI-12345-trunk. Again this could be
   anything as long as you can differentiate.
   - After committing patches to both the newly created branches, you need
   to open two pull requests against two public branches - branch2.6 and
   trunk. This link should help -
   https://help.github.com/articles/creating-a-pull-request-from-a-fork/
   - If there is no conflict, github offers "squash and merge" option which
   will let you remove unnecessary commit messages and merge any number of
   commits as one commit. For more info -
   https://help.github.com/articles/about-pull-request-merges

Hope this clarifies the flow.

To clarify Jonathan's suggestion

* I do not think that adding a [COMPONENT] tag is useful. Many commits span
ambari-server and ambari-agent, and a good number also span ambari-web and
ambari-server. I also think that we should have the title of the JIra match
the commit exactly as we do today.

If a commit spans multiple components, lets say ambari-server and
ambari-web, the PR title should be [AMBARI-12345][ambari-server][ambari-web]
Title. This is especially useful to categorize the open pull requests based
on their components, so that other folks working in those components can
work on clearing those open pull requests.

Please let me know if you need more clarification on anything discussed
here.

Thanks,
Vivek Ratnavel

On Thu, Jan 4, 2018 at 8:45 AM, Nate Cole <ncole@hortonworks.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message