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 <[email protected]> wrote: > +1 to open a new pull request. > > On Mon, Jan 8, 2018 at 2:25 PM, Jonathan Hurley <[email protected]> > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected]<mailto: >> [email protected]><mailto:[email protected]>> >> Reply-To: "[email protected]<mailto:[email protected]><mailto: >> [email protected]>" <[email protected]<mailto: >> [email protected]><mailto:[email protected]>> >> Date: Friday, January 5, 2018 at 12:16 AM >> To: "[email protected]<mailto:[email protected]><mailto: >> [email protected]>" <[email protected]<mailto: >> [email protected]><mailto:[email protected]>> >> 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 <[email protected] >> <mailto:[email protected]><mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]><mailto:[email protected]>> >> 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 <[email protected]<mailto: >> [email protected]><mailto:[email protected]>> 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" <[email protected]<ma >> ilto:[email protected]><mailto:[email protected]>> >> 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 >> >> >
