Page History

...

1. • Fork the project from Github at https://github.com/apache/ambari if you haven't already 

   • Clone this fork: 

     Code Block
     language bash
     git clone https://github.com/username/ambari.git /target/path# Replace [forked-repository-url] with your git clone url git clone [forked-repository-url] ambari

   • Set upstream remote:

     Code Block
     language bash
     cd /target/pathambari git remote add upstream https://gitboxgithub.apache.org/repos/asfcom/apache/ambari.git

2. Keep your Fork Up to Date

   Code Block
   language bash
   # Fetch from upstream remote git fetch upstream # Checkout the branch that needs to sync git checkout trunk # Merge with remote git merge upstream/trunk

   Repeat these steps for all the branches that needs to be synced with the remote.

3. JIRA

   Apache Ambari uses JIRA to track issues including bugs and improvements, and uses Github pull requests to manage code reviews and code merges. Major design changes are discussed in JIRA and implementation changes are discussed in pull requests after a pull request is created.

   1. Find an existing Apache JIRA that the change pertains to

   1. 1. Do not create a new JIRA if the change is minor and relates to an existing JIRA; add to the existing discussion and work instead

      2. Look for existing pull requests that are linked from the JIRA, to understand if someone is already working on the JIRA

   2. If the change is new, then create a new JIRA:
      1. Provide a descriptive Title
      2. Write a detailed Description. For bug reports, this should ideally include a short reproduction of the problem. For new features, it may include a design document.
      3. Fill the required fields:
         1. Issue Type. Bug and Task are the most frequently used issue types in Ambari.
         2. Priority. Their meaning is roughly:
            1. Blocker: pointless to release without this change as the release would be unusable to a large minority of users
            2. Critical: a large minority of users are missing important functionality without this, and/or a workaround is difficult
            3. Major: a small minority of users are missing important functionality without this, and there is a workaround
            4. Minor: a niche use case is missing some support, but it does not affect usage or is easily worked around
            5. Trivial: a nice-to-have change but unlikely to be any problem in practice otherwise
         3. Component. Choose the components that are affected by this change. Choose from Ambari Components
         4. Affects Version. For Bugs, assign at least one version that is known to exhibit the problem or need the change
      4. Do not include a patch file; pull requests are used to propose the actual change.
         
         

4. Pull Request

   Apache Ambari uses Github pull requests to review and merge changes to the source code. Before creating a pull request, one must have a fork of apache/ambari checked out. Follow instructions in step 1 to create a fork if you haven't already.

...