You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Vivek Ratnavel <vi...@apache.org> on 2018/01/03 23:55:53 UTC
[DISCUSS] Future code review and commit process
Hi all,
As we are linking our github accounts with gitbox to gain write access to
github repository, I wanted to start a discussion on the future code review
and commit process.
After taking a look at other Apache projects including Apache Spark, I
suggest we adapt the following flow:
- A JIRA is created with all the required details at
https://issues.apache.org/
- Create a new branch from local fork and push commits to that branch
- Run all the tests and update or add new tests if required
- Open a pull request against trunk or any other branch. I suggest using
PR title format similar to what Apache Spark is using.
1. The pull request title should be of the form [AMBARI-xxxx][COMPONENT]
Title, where AMBARI-xxxx is the relevant JIRA number, COMPONENT is
one of the ambari components such as ambari-server, ambari-web, etc. and
Title may be the JIRA’s title or a more specific title describing the
PR itself.
2. If the pull request is still a work in progress, and so is not
ready to be merged, but needs to be pushed to Github to
facilitate review,
then add [WIP] after the component.
Following such a format to create pull requests will help us create a
portal such as https://spark-prs.appspot.com/ in the future to keep track
of open pull requests. Thanks to github's rich set of APIs.
- Wait for a +1 or approval of PR from any committer. If there is a need
for update, keep pushing commits to the same branch and notify the reviewer
of the update.
- If a PR has +1 from a committer, any committer can then go ahead and
merge the PR and mark the JIRA as resolved
Please let me know what you think about this flow. Your feedback is
appreciated.
Thanks,
Vivek Ratnavel
Re: [DISCUSS] Future code review and commit process
Posted by Nate Cole <nc...@hortonworks.com>.
We should make it very clear how these jira-feature-branches (“jira-branch”) are built.
If you are working from a feature-branch (not trunk) then your jira-branch must come from that feature-branch. In addition, you cannot merge from trunk, bypassing your base feature-branch.
When merging from your feature-branch while you work on your jira-branch, you should use the fast-forward option so that we don’t end up with hundreds of merge commits.
On 1/3/18, 6:55 PM, "Vivek Ratnavel" <vi...@apache.org> wrote:
Hi all,
As we are linking our github accounts with gitbox to gain write access to
github repository, I wanted to start a discussion on the future code review
and commit process.
After taking a look at other Apache projects including Apache Spark, I
suggest we adapt the following flow:
- A JIRA is created with all the required details at
https://issues.apache.org/
- Create a new branch from local fork and push commits to that branch
- Run all the tests and update or add new tests if required
- Open a pull request against trunk or any other branch. I suggest using
PR title format similar to what Apache Spark is using.
1. The pull request title should be of the form [AMBARI-xxxx][COMPONENT]
Title, where AMBARI-xxxx is the relevant JIRA number, COMPONENT is
one of the ambari components such as ambari-server, ambari-web, etc. and
Title may be the JIRA’s title or a more specific title describing the
PR itself.
2. If the pull request is still a work in progress, and so is not
ready to be merged, but needs to be pushed to Github to
facilitate review,
then add [WIP] after the component.
Following such a format to create pull requests will help us create a
portal such as https://spark-prs.appspot.com/ in the future to keep track
of open pull requests. Thanks to github's rich set of APIs.
- Wait for a +1 or approval of PR from any committer. If there is a need
for update, keep pushing commits to the same branch and notify the reviewer
of the update.
- If a PR has +1 from a committer, any committer can then go ahead and
merge the PR and mark the JIRA as resolved
Please let me know what you think about this flow. Your feedback is
appreciated.
Thanks,
Vivek Ratnavel
Re: [DISCUSS] Future code review and commit process
Posted by Vivek Ratnavel <vi...@apache.org>.
Hi Team,
The Apache Infrastructure team has successfully moved ambari git repo to
gitbox.
New remote url: https://gitbox.apache.org/repos/asf/ambari.git
If you have a local clone and would like to just update the remote url,
then follow these steps:
1. Fork <https://help.github.com/articles/fork-a-repo/> the
https://github.com/apache/ambari repo in github.
2. Run "git remote set-url origin [remote-url]". Replace the
[remote-url] with your fork's remote url. This would be of the form
https://github.com/username/ambari.git
3. Run "git remote add upstream https://gitbox.apache.org
/repos/asf/ambari.git"
I have updated the How to Contribute
<https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute>
guide for detailed instructions on creating pull requests and reviewing
patches. I have created this guide by taking suggestions discussed in this
email thread and by referring to other Apache project's contribution guides.
Please take a look and let me know if you would like any part of the
documentation edited.
Cheers,
Vivek Ratnavel
On Mon, Jan 8, 2018 at 4:58 PM, Vivek Ratnavel <vi...@apache.org>
wrote:
> +1 to open a new pull request.
>
> On Mon, Jan 8, 2018 at 2:25 PM, Jonathan Hurley <jh...@hortonworks.com>
> wrote:
>
>> My vote would be to open a new pull request - if anything just to get
>> more practice. Even if you already have +1's, it's good to open it and
>> reference the reviewboard.
>>
>> On Jan 8, 2018, at 2:00 PM, Attila Doroszlai <adoroszlai@hortonworks.com
>> <ma...@hortonworks.com>> wrote:
>>
>> Is there a policy for pending review requests (ie. the ones already open
>> at https://reviews.apache.org/groups/Ambari/ )? Should we open a PR for
>> each, or should they be wrapped up on Review Board, or is it up to us?
>>
>> Thanks.
>>
>> -Attila
>>
>> From: Vivek Ratnavel <vivekratnavel@apache.org<mailto:
>> vivekratnavel@apache.org><ma...@apache.org>>
>> Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org><mailto:
>> dev@ambari.apache.org>" <dev@ambari.apache.org<mailto:
>> dev@ambari.apache.org><ma...@ambari.apache.org>>
>> Date: Friday, January 5, 2018 at 12:16 AM
>> To: "dev@ambari.apache.org<ma...@ambari.apache.org><mailto:
>> dev@ambari.apache.org>" <dev@ambari.apache.org<mailto:
>> dev@ambari.apache.org><ma...@ambari.apache.org>>
>> Subject: Re: [DISCUSS] Future code review and commit process
>>
>> Further clarifications:
>>
>> - Creating the fork
>> https://help.github.com/articles/fork-a-repo/
>>
>> - Creating a branch for every commit (and creating the pull request)
>> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>>
>> - How to keep your fork in-sync with the upstream repository
>>
>> https://help.github.com/articles/syncing-a-fork/
>>
>> - How long-lived Apache feature branches will work in this model. In this
>> case, we'd still need a branch off of the feature branch for every commit
>> from the fork.
>>
>> In this workflow, a feature branch is no different than any other branch.
>> If you want a commit to land in a branch, then you create a new branch
>> based off that branch. You create multiple branches if you want your
>> commits to land in multiple branches. It might sound like a daunting task
>> initially, but believe me, its very easy and straightforward to create a
>> branch and open pull requests for review. And once a pull request is
>> opened, you can make changes by simply pushing commits to the same branch.
>>
>> - How to merge long-lived feature branches into Apache
>>
>> Feature branches or any other branch could be merged with trunk or any
>> branch by creating a new pull request. A new pull request could be opened
>> by selecting two branches - a base branch and a head branch. In this case,
>> if you want to merge a feature branch with trunk, then you select feature
>> branch as base branch and trunk as head branch.
>>
>> I have attached a screen-shot for reference.
>>
>> [cid:ii_jc13wnyl0_160c3724ae47072e]
>>
>>
>> I agree with you on creating a wiki page to cover all the scenarios.
>>
>>
>> Thanks,
>> Vivek Ratnavel
>>
>>
>>
>> On Thu, Jan 4, 2018 at 1:05 PM, Jonathan Hurley <jhurley@hortonworks.com
>> <ma...@hortonworks.com>> wrote:
>> Thanks for the clarifications. This sounds like the "Forking Workflow" as
>> opposed to the "Feature Branch Workflow". I'm fine with that since it lets
>> non-commiters help.
>>
>> We should try to capture all of these scenarios in a wiki page which we
>> can then all agree upon. Things which we need to cover are:
>>
>> - Creating the fork
>> - Creating a branch for every commit (and creating the pull request)
>> - How to keep your fork in-sync with the upstream repository
>> - How long-lived Apache feature branches will work in this model. In this
>> case, we'd still need a branch off of the feature branch for every commit
>> from the fork.
>> - How to merge long-lived feature branches into Apache
>>
>> A few of the items above haven't been specified yet - like keeping the
>> forked repo in sync and how to manage long-lived feature branches in Apache.
>>
>> I still do not think we need [component-1][component-2] in the commit
>> message. We can use the fields in Apache Jira for this. It makes our commit
>> messages long, hard to read, and ugly.
>>
>> On Jan 4, 2018, at 12:57 PM, Vivek Ratnavel <vivekratnavel@apache.org
>> <ma...@apache.org>>
>> wrote:
>>
>> 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<mailto:
>> ncole@hortonworks.com><ma...@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<ma
>> ilto:adoroszlai@hortonworks.com><ma...@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
>>
>>
>
Re: [DISCUSS] Future code review and commit process
Posted by Vivek Ratnavel <vi...@apache.org>.
+1 to open a new pull request.
On Mon, Jan 8, 2018 at 2:25 PM, Jonathan Hurley <jh...@hortonworks.com>
wrote:
> My vote would be to open a new pull request - if anything just to get more
> practice. Even if you already have +1's, it's good to open it and reference
> the reviewboard.
>
> On Jan 8, 2018, at 2:00 PM, Attila Doroszlai <adoroszlai@hortonworks.com<
> mailto:adoroszlai@hortonworks.com>> wrote:
>
> Is there a policy for pending review requests (ie. the ones already open
> at https://reviews.apache.org/groups/Ambari/ )? Should we open a PR for
> each, or should they be wrapped up on Review Board, or is it up to us?
>
> Thanks.
>
> -Attila
>
> From: Vivek Ratnavel <vivekratnavel@apache.org<mailto:
> vivekratnavel@apache.org><ma...@apache.org>>
> Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org><mailto:
> dev@ambari.apache.org>" <dev@ambari.apache.org<mailto:
> dev@ambari.apache.org><ma...@ambari.apache.org>>
> Date: Friday, January 5, 2018 at 12:16 AM
> To: "dev@ambari.apache.org<ma...@ambari.apache.org><mailto:
> dev@ambari.apache.org>" <dev@ambari.apache.org<mailto:
> dev@ambari.apache.org><ma...@ambari.apache.org>>
> Subject: Re: [DISCUSS] Future code review and commit process
>
> Further clarifications:
>
> - Creating the fork
> https://help.github.com/articles/fork-a-repo/
>
> - Creating a branch for every commit (and creating the pull request)
> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>
> - How to keep your fork in-sync with the upstream repository
>
> https://help.github.com/articles/syncing-a-fork/
>
> - How long-lived Apache feature branches will work in this model. In this
> case, we'd still need a branch off of the feature branch for every commit
> from the fork.
>
> In this workflow, a feature branch is no different than any other branch.
> If you want a commit to land in a branch, then you create a new branch
> based off that branch. You create multiple branches if you want your
> commits to land in multiple branches. It might sound like a daunting task
> initially, but believe me, its very easy and straightforward to create a
> branch and open pull requests for review. And once a pull request is
> opened, you can make changes by simply pushing commits to the same branch.
>
> - How to merge long-lived feature branches into Apache
>
> Feature branches or any other branch could be merged with trunk or any
> branch by creating a new pull request. A new pull request could be opened
> by selecting two branches - a base branch and a head branch. In this case,
> if you want to merge a feature branch with trunk, then you select feature
> branch as base branch and trunk as head branch.
>
> I have attached a screen-shot for reference.
>
> [cid:ii_jc13wnyl0_160c3724ae47072e]
>
>
> I agree with you on creating a wiki page to cover all the scenarios.
>
>
> Thanks,
> Vivek Ratnavel
>
>
>
> On Thu, Jan 4, 2018 at 1:05 PM, Jonathan Hurley <jhurley@hortonworks.com<
> mailto:jhurley@hortonworks.com><ma...@hortonworks.com>> wrote:
> Thanks for the clarifications. This sounds like the "Forking Workflow" as
> opposed to the "Feature Branch Workflow". I'm fine with that since it lets
> non-commiters help.
>
> We should try to capture all of these scenarios in a wiki page which we
> can then all agree upon. Things which we need to cover are:
>
> - Creating the fork
> - Creating a branch for every commit (and creating the pull request)
> - How to keep your fork in-sync with the upstream repository
> - How long-lived Apache feature branches will work in this model. In this
> case, we'd still need a branch off of the feature branch for every commit
> from the fork.
> - How to merge long-lived feature branches into Apache
>
> A few of the items above haven't been specified yet - like keeping the
> forked repo in sync and how to manage long-lived feature branches in Apache.
>
> I still do not think we need [component-1][component-2] in the commit
> message. We can use the fields in Apache Jira for this. It makes our commit
> messages long, hard to read, and ugly.
>
> On Jan 4, 2018, at 12:57 PM, Vivek Ratnavel <vivekratnavel@apache.org<
> mailto:vivekratnavel@apache.org><ma...@apache.org>> wrote:
>
> 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<mailto:
> ncole@hortonworks.com><ma...@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<
> mailto:adoroszlai@hortonworks.com><ma...@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
>
>
Re: [DISCUSS] Future code review and commit process
Posted by Jonathan Hurley <jh...@hortonworks.com>.
My vote would be to open a new pull request - if anything just to get more practice. Even if you already have +1's, it's good to open it and reference the reviewboard.
On Jan 8, 2018, at 2:00 PM, Attila Doroszlai <ad...@hortonworks.com>> wrote:
Is there a policy for pending review requests (ie. the ones already open at https://reviews.apache.org/groups/Ambari/ )? Should we open a PR for each, or should they be wrapped up on Review Board, or is it up to us?
Thanks.
-Attila
From: Vivek Ratnavel <vi...@apache.org>>
Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
Date: Friday, January 5, 2018 at 12:16 AM
To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
Subject: Re: [DISCUSS] Future code review and commit process
Further clarifications:
- Creating the fork
https://help.github.com/articles/fork-a-repo/
- Creating a branch for every commit (and creating the pull request)
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
- How to keep your fork in-sync with the upstream repository
https://help.github.com/articles/syncing-a-fork/
- How long-lived Apache feature branches will work in this model. In this case, we'd still need a branch off of the feature branch for every commit from the fork.
In this workflow, a feature branch is no different than any other branch. If you want a commit to land in a branch, then you create a new branch based off that branch. You create multiple branches if you want your commits to land in multiple branches. It might sound like a daunting task initially, but believe me, its very easy and straightforward to create a branch and open pull requests for review. And once a pull request is opened, you can make changes by simply pushing commits to the same branch.
- How to merge long-lived feature branches into Apache
Feature branches or any other branch could be merged with trunk or any branch by creating a new pull request. A new pull request could be opened by selecting two branches - a base branch and a head branch. In this case, if you want to merge a feature branch with trunk, then you select feature branch as base branch and trunk as head branch.
I have attached a screen-shot for reference.
[cid:ii_jc13wnyl0_160c3724ae47072e]
I agree with you on creating a wiki page to cover all the scenarios.
Thanks,
Vivek Ratnavel
On Thu, Jan 4, 2018 at 1:05 PM, Jonathan Hurley <jh...@hortonworks.com>> wrote:
Thanks for the clarifications. This sounds like the "Forking Workflow" as opposed to the "Feature Branch Workflow". I'm fine with that since it lets non-commiters help.
We should try to capture all of these scenarios in a wiki page which we can then all agree upon. Things which we need to cover are:
- Creating the fork
- Creating a branch for every commit (and creating the pull request)
- How to keep your fork in-sync with the upstream repository
- How long-lived Apache feature branches will work in this model. In this case, we'd still need a branch off of the feature branch for every commit from the fork.
- How to merge long-lived feature branches into Apache
A few of the items above haven't been specified yet - like keeping the forked repo in sync and how to manage long-lived feature branches in Apache.
I still do not think we need [component-1][component-2] in the commit message. We can use the fields in Apache Jira for this. It makes our commit messages long, hard to read, and ugly.
On Jan 4, 2018, at 12:57 PM, Vivek Ratnavel <vi...@apache.org>> wrote:
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 <nc...@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" <ad...@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
Re: [DISCUSS] Future code review and commit process
Posted by Attila Doroszlai <ad...@hortonworks.com>.
Is there a policy for pending review requests (ie. the ones already open at https://reviews.apache.org/groups/Ambari/ )? Should we open a PR for each, or should they be wrapped up on Review Board, or is it up to us?
Thanks.
-Attila
From: Vivek Ratnavel <vi...@apache.org>>
Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
Date: Friday, January 5, 2018 at 12:16 AM
To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
Subject: Re: [DISCUSS] Future code review and commit process
Further clarifications:
- Creating the fork
https://help.github.com/articles/fork-a-repo/
- Creating a branch for every commit (and creating the pull request)
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
- How to keep your fork in-sync with the upstream repository
https://help.github.com/articles/syncing-a-fork/
- How long-lived Apache feature branches will work in this model. In this case, we'd still need a branch off of the feature branch for every commit from the fork.
In this workflow, a feature branch is no different than any other branch. If you want a commit to land in a branch, then you create a new branch based off that branch. You create multiple branches if you want your commits to land in multiple branches. It might sound like a daunting task initially, but believe me, its very easy and straightforward to create a branch and open pull requests for review. And once a pull request is opened, you can make changes by simply pushing commits to the same branch.
- How to merge long-lived feature branches into Apache
Feature branches or any other branch could be merged with trunk or any branch by creating a new pull request. A new pull request could be opened by selecting two branches - a base branch and a head branch. In this case, if you want to merge a feature branch with trunk, then you select feature branch as base branch and trunk as head branch.
I have attached a screen-shot for reference.
[cid:ii_jc13wnyl0_160c3724ae47072e]
I agree with you on creating a wiki page to cover all the scenarios.
Thanks,
Vivek Ratnavel
On Thu, Jan 4, 2018 at 1:05 PM, Jonathan Hurley <jh...@hortonworks.com>> wrote:
Thanks for the clarifications. This sounds like the "Forking Workflow" as opposed to the "Feature Branch Workflow". I'm fine with that since it lets non-commiters help.
We should try to capture all of these scenarios in a wiki page which we can then all agree upon. Things which we need to cover are:
- Creating the fork
- Creating a branch for every commit (and creating the pull request)
- How to keep your fork in-sync with the upstream repository
- How long-lived Apache feature branches will work in this model. In this case, we'd still need a branch off of the feature branch for every commit from the fork.
- How to merge long-lived feature branches into Apache
A few of the items above haven't been specified yet - like keeping the forked repo in sync and how to manage long-lived feature branches in Apache.
I still do not think we need [component-1][component-2] in the commit message. We can use the fields in Apache Jira for this. It makes our commit messages long, hard to read, and ugly.
> On Jan 4, 2018, at 12:57 PM, Vivek Ratnavel <vi...@apache.org>> wrote:
>
> 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 <nc...@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" <ad...@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
>>
>>
>>
Re: [DISCUSS] Future code review and commit process
Posted by Vivek Ratnavel <vi...@apache.org>.
Further clarifications:
- Creating the fork
https://help.github.com/articles/fork-a-repo/
- Creating a branch for every commit (and creating the pull request)
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
- How to keep your fork in-sync with the upstream repository
https://help.github.com/articles/syncing-a-fork/
- How long-lived Apache feature branches will work in this model. In this
case, we'd still need a branch off of the feature branch for every commit
from the fork.
In this workflow, a feature branch is no different than any other branch.
If you want a commit to land in a branch, then you create a new branch
based off that branch. You create multiple branches if you want your
commits to land in multiple branches. It might sound like a daunting task
initially, but believe me, its very easy and straightforward to create a
branch and open pull requests for review. And once a pull request is
opened, you can make changes by simply pushing commits to the same branch.
- How to merge long-lived feature branches into Apache
Feature branches or any other branch could be merged with trunk or any
branch by creating a new pull request. A new pull request could be opened
by selecting two branches - a base branch and a head branch. In this case,
if you want to merge a feature branch with trunk, then you select feature
branch as base branch and trunk as head branch.
I have attached a screen-shot for reference.
I agree with you on creating a wiki page to cover all the scenarios.
Thanks,
Vivek Ratnavel
On Thu, Jan 4, 2018 at 1:05 PM, Jonathan Hurley <jh...@hortonworks.com>
wrote:
> Thanks for the clarifications. This sounds like the "Forking Workflow" as
> opposed to the "Feature Branch Workflow". I'm fine with that since it lets
> non-commiters help.
>
> We should try to capture all of these scenarios in a wiki page which we
> can then all agree upon. Things which we need to cover are:
>
> - Creating the fork
> - Creating a branch for every commit (and creating the pull request)
> - How to keep your fork in-sync with the upstream repository
> - How long-lived Apache feature branches will work in this model. In this
> case, we'd still need a branch off of the feature branch for every commit
> from the fork.
> - How to merge long-lived feature branches into Apache
>
> A few of the items above haven't been specified yet - like keeping the
> forked repo in sync and how to manage long-lived feature branches in Apache.
>
> I still do not think we need [component-1][component-2] in the commit
> message. We can use the fields in Apache Jira for this. It makes our commit
> messages long, hard to read, and ugly.
>
> > On Jan 4, 2018, at 12:57 PM, Vivek Ratnavel <vi...@apache.org>
> wrote:
> >
> > 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 <nc...@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" <ad...@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
> >>
> >>
> >>
>
>
Re: [DISCUSS] Future code review and commit process
Posted by Jonathan Hurley <jh...@hortonworks.com>.
Thanks for the clarifications. This sounds like the "Forking Workflow" as opposed to the "Feature Branch Workflow". I'm fine with that since it lets non-commiters help.
We should try to capture all of these scenarios in a wiki page which we can then all agree upon. Things which we need to cover are:
- Creating the fork
- Creating a branch for every commit (and creating the pull request)
- How to keep your fork in-sync with the upstream repository
- How long-lived Apache feature branches will work in this model. In this case, we'd still need a branch off of the feature branch for every commit from the fork.
- How to merge long-lived feature branches into Apache
A few of the items above haven't been specified yet - like keeping the forked repo in sync and how to manage long-lived feature branches in Apache.
I still do not think we need [component-1][component-2] in the commit message. We can use the fields in Apache Jira for this. It makes our commit messages long, hard to read, and ugly.
> On Jan 4, 2018, at 12:57 PM, Vivek Ratnavel <vi...@apache.org> wrote:
>
> 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 <nc...@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" <ad...@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
>>
>>
>>
Re: [DISCUSS] Future code review and commit process
Posted by Vivek Ratnavel <vi...@apache.org>.
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 <nc...@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" <ad...@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
>
>
>
Re: [DISCUSS] Future code review and commit process
Posted by Nate Cole <nc...@hortonworks.com>.
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" <ad...@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
Re: [DISCUSS] Future code review and commit process
Posted by Jonathan Hurley <jh...@hortonworks.com>.
Yes, I mis-read the original email from Vivek. You have to work in your own fork of Ambari. Every pull request is done between the public branch and a branch in your local forked repo, right?
> On Jan 4, 2018, at 11:32 AM, Attila Doroszlai <ad...@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
Re: [DISCUSS] Future code review and commit process
Posted by Attila Doroszlai <ad...@hortonworks.com>.
> * 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
Re: [DISCUSS] Future code review and commit process
Posted by Jonathan Hurley <jh...@hortonworks.com>.
This model is quite different from the model which many of us have been using years. As such, I think we need to define a bit more structure so that we keep the project tidy and under control. A few points:
* 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.
* We should also take this opportunity to go through any of our existing branches and clean out the ones which are very stale and not related to a prior release or existing feature under development. We have a branch named "trunkj" ...
* Using longer-lived feature branches should remain similar to today and should work nicely with this model. When merging them incrementally, we can just keep them open after the pull request is merged.
* 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.
On Jan 3, 2018, at 6:55 PM, Vivek Ratnavel <vi...@apache.org>> wrote:
Hi all,
As we are linking our github accounts with gitbox to gain write access to
github repository, I wanted to start a discussion on the future code review
and commit process.
After taking a look at other Apache projects including Apache Spark, I
suggest we adapt the following flow:
- A JIRA is created with all the required details at
https://issues.apache.org/
- Create a new branch from local fork and push commits to that branch
- Run all the tests and update or add new tests if required
- Open a pull request against trunk or any other branch. I suggest using
PR title format similar to what Apache Spark is using.
1. The pull request title should be of the form [AMBARI-xxxx][COMPONENT]
Title, where AMBARI-xxxx is the relevant JIRA number, COMPONENT is
one of the ambari components such as ambari-server, ambari-web, etc. and
Title may be the JIRA’s title or a more specific title describing the
PR itself.
2. If the pull request is still a work in progress, and so is not
ready to be merged, but needs to be pushed to Github to
facilitate review,
then add [WIP] after the component.
Following such a format to create pull requests will help us create a
portal such as https://spark-prs.appspot.com/ in the future to keep track
of open pull requests. Thanks to github's rich set of APIs.
- Wait for a +1 or approval of PR from any committer. If there is a need
for update, keep pushing commits to the same branch and notify the reviewer
of the update.
- If a PR has +1 from a committer, any committer can then go ahead and
merge the PR and mark the JIRA as resolved
Please let me know what you think about this flow. Your feedback is
appreciated.
Thanks,
Vivek Ratnavel