gitbox migration - git-wip is gone. new remote?

[Yusaku Sako]

Vivek,

Thanks for driving the gitbox migration effort.
It seems like INFRA has performed the migration step:
https://git-wip-us.apache.org/repos/asf/ambari.git/ is gone now.

What’s the new URL for git remote?

Yusaku

Re: gitbox migration - git-wip is gone. new remote?

[Kevin Risden]

Gitbox repos are listed here: https://gitbox.apache.org/repos/asf

Kevin Risden

On Mon, Jan 8, 2018 at 2:19 PM, Yusaku Sako  wrote:

> Vivek,
>
> Thanks for driving the gitbox migration effort.
> It seems like INFRA has performed the migration step:
> https://git-wip-us.apache.org/repos/asf/ambari.git/ is gone now.
>
> What’s the new URL for git remote?
>
> Yusaku
>
>
>

Re: gitbox migration - git-wip is gone. new remote?

[Yusaku Sako]

Thanks Kevin.

Git web URL: https://gitbox.apache.org/repos/asf?p=ambari.git
Git remote URL: https://gitbox.apache.org/repos/asf/ambari.git

Yusaku

On 1/8/18, 12:21 PM, "Kevin Risden"  wrote:

Gitbox repos are listed here: https://gitbox.apache.org/repos/asf

Kevin Risden

On Mon, Jan 8, 2018 at 2:19 PM, Yusaku Sako  wrote:

> Vivek,
>
> Thanks for driving the gitbox migration effort.
> It seems like INFRA has performed the migration step:
> https://git-wip-us.apache.org/repos/asf/ambari.git/ is gone now.
>
> What’s the new URL for git remote?
>
> Yusaku
>
>
>

Re: gitbox migration - git-wip is gone. new remote?

[Kevin Risden]

The new remote url that worked for me:

https://gitbox.apache.org/repos/asf/ambari.git

Kevin Risden

On Mon, Jan 8, 2018 at 2:21 PM, Kevin Risden  wrote:

> Gitbox repos are listed here: https://gitbox.apache.org/repos/asf
>
> Kevin Risden
>
> On Mon, Jan 8, 2018 at 2:19 PM, Yusaku Sako 
> wrote:
>
>> Vivek,
>>
>> Thanks for driving the gitbox migration effort.
>> It seems like INFRA has performed the migration step:
>> https://git-wip-us.apache.org/repos/asf/ambari.git/ is gone now.
>>
>> What’s the new URL for git remote?
>>
>> Yusaku
>>
>>
>>
>

Re: [DISCUSS] Future code review and commit process

[Attila Doroszlai]

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 mailto:vivekratna...@apache.org>>
Reply-To: "dev@ambari.apache.org" 
mailto:dev@ambari.apache.org>>
Date: Friday, January 5, 2018 at 12:16 AM
To: "dev@ambari.apache.org" 
mailto:dev@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 
mailto:jhur...@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 
> mailto:vivekratna...@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

Re: [DISCUSS] Future code review and commit process

[Jonathan Hurley]

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 
mailto:adorosz...@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 
mailto:vivekratna...@apache.org>>
Reply-To: 
"dev@ambari.apache.org"
 
mailto:dev@ambari.apache.org>>
Date: Friday, January 5, 2018 at 12:16 AM
To: 
"dev@ambari.apache.org"
 
mailto:dev@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 
mailto:jhur...@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 
mailto:vivekratna...@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
 commit

Re: [DISCUSS] Future code review and commit process

[Vivek Ratnavel]

+1 to open a new pull request.

On Mon, Jan 8, 2018 at 2:25 PM, Jonathan Hurley 
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  mailto:adorosz...@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  vivekratna...@apache.org>>
> Reply-To: "dev@ambari.apache.org dev@ambari.apache.org>"  dev@ambari.apache.org>>
> Date: Friday, January 5, 2018 at 12:16 AM
> To: "dev@ambari.apache.org dev@ambari.apache.org>"  dev@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  mailto:jhur...@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  mailto:vivekratna...@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.g

Re: [DISCUSS] Future code review and commit process

[Vivek Ratnavel]

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  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

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 
wrote:

> +1 to open a new pull request.
>
> On Mon, Jan 8, 2018 at 2:25 PM, Jonathan Hurley 
> 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 > > 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 > vivekratna...@apache.org>>
>> Reply-To: "dev@ambari.apache.org> dev@ambari.apache.org>" > dev@ambari.apache.org>>
>> Date: Friday, January 5, 2018 at 12:16 AM
>> To: "dev@ambari.apache.org> dev@ambari.apache.org>" > dev@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 > > 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