This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Apache Mnemonic project developed by Java and C languages. Like any other Apache open source project, we have several ways to contribute to the project. Some of which are documentation improvements, code reviews, code changes, helping users on mailing lists, helping in release candidate testing, etc.

To become an effective contributor, we can follow certain guidelines for each of these contribution catogeries mentioned above. Let's go through the following sections for more details.

Documentation Changes

For any new contributor to the project, we strongly encourage to go through the documentation for better understanding the project. We can find the documentation from the Mnemonic website.

Note: this site is under construction at this stage, soon it will be active.

While going through the documentation, you may find some improvements/suggestion to the documentation. When you find these changes, please raise a JIRA ticket and if you want to fix it your won, we welcome you to create a pull request against trunk and submit it to JIRA.

Please look at the documentation for how to build website and documentation.[TODO: link to the page for building website and documentation page]

Code Reviews

Apache Mnemonic project code contributions will be submitted via pull requests and these pull request link will be commented in JIRA. Any one can comment on these JIRA issues or pull request. Once you get the architectural understanding, you may be helpful in reviewing other contributor patches. Feel free to provide your feedbacks on other contributor patches on pull request or in JIRA.

These comments can be pointing out issues, questions, style issues, typos etc. Involving in reviews will help better understanding various code paths, process of code contributions, and help more bonding with other contributions.

Not only code logic changes, you can also focus on following type of issues:

  • Whether enough test cases added for the code change
  • Whether code fully compliant to the Apache Mnemonic coding guidelines
  • Make sure code changes are completely relevant to the current issue
  • Check unused imports left out
  • Make sure better javadocs/documentation/comments added
  • Make sure better logging added
  • Check the typos
  • Ask user confirmation whether he tested manually some special cases if we can not automat some corner cases.
  • Check for better class/method/variable names

Code Changes

Generally for code changes, contributor should have gained enough knowledge on the code base to change the code. Documentation would be the best first source for getting better understanding the system. 

For code changes, contributors need to clone the repository to local machines. Since we follow the contributions via the git pullrequest method we need to follow certain steps.

  • Git Pull Request work flow

     1. First of all, contributor needs github account if you don't have one already. 

     2. Then fork the Apache Mnemonic git repository to your account.

     3. Then go to your machine's git shell command prompt and clone your forked repository. Command: git clone <FORKED_REPO.git>. 

         This will have one remote that will be named as origin by default.

     4. Then git remote add original branch as upstream. Command: git remote add upstream <ORIGINAL_REPO.git>. 

         You can update branch like :git fetch upstream/master

         So, now we have 2 remotes(origin, upstream) added. Origin is for forked repository and upstream is for original Mnemonic apache repository. 

     5. Create local branch for your work at forked branch master. Command: git checkout -b <branch-name>. 

      So, here master is default trunk code base and <branch-name> is the working branch on forked repo.


    5) create local branch for your work at forked branch master. Lets say branch test. then master and test are the code 2 bases. Push this created branch to your forked repo.
    4) git checkout test if you are in master. Do your work here
    5) then get pull request from UI by comparing to base forked branch to your local created and pushed branch test.
    6) After creating pull and merged to main repo, you can safely remove this test branch.
    7. after that you can upto date forked master with upstream master by : git rebase upstream/master


  • No labels