Page History

Note: This page is work in progress.

This workflow page is modeled after Spark Spark Contributing to Spark and Beam Become a Committer

There are many ways to contribute to Rya. We'll try to document them here. All contributions, code or not code, are important. 

Contributions:

There are many actions other than coding that build the trust we place in a committer - code review, design discussion, user support, community outreach, improving infrastructure, documentation, project management, etc. Here are some types of contributions. Any positive contribution to the project is welcome:

• Use our project and provide feedback.
• Ask and answer questions on the dev@rya.apache.org users list
• Contribute javadocs, documentation.
• Provide us with use-cases.
• Report bugs and submit patches.
• Contribute code.
• Contribute to the Rya website
• Help spread the word about the project
• Review pull requests
• Verify releases
• Anything else that contributes to health of the Rya project and community

To report a bug/propose work:

-others can review the pull request and possibly suggest changes

-a committer will look review at it the pull request and integrate it in the code /or not

What does it mean to be a committer:

An Apache Rya committer has write access to the repository for merging pull requests, but you don’t have to be a code contributor to become a committer. Becoming a committer means that you have the project’s trust. Read the ASF documentation for more about being a committer in the Apache Software Foundation.

How to become a committer:

To find out how to become a committer for Rya, please read the ASF guides listed below. If you contribute to the project and show commitment to the project and ASF values of open communication, inclusion, diversity, meritocracy, the current committers will notice and it is likely they will invite you to become a committer.

http://www.apache.org/dev/new-committers-guide.html

http://www.apache.org/foundation/getinvolved.html#become-a-committer 

Commit Process for Committers:

Step 0: Clone and Update your local copy of Apache Rya -Incubator repository

Step 1: Add a remote to the fork referenced in the PR and fetch the branch in the PR.

...

Step 5: Update JIRA Ticket 

Step 0.1: Clone the Apache Rya -Incubator repository

git clone https://git-wip-usgitbox.apache.org/repos/asf/incubator-rya.git incubator- rya-apache

Step 0.2: Update your repository

...

git remote add jej2003 https://github.com/jej2003/incubator-rya.git
git fetch jej2003 input_format_fix
git checkout input_format_fix 

...

Set the click on the "Close Issue" button in JIRA.

Commit Process for Committers for the Apache Rya Website:

The repository for Apache Rya website is at https://gitbox.apache.org/repos/asf/rya-site.git.  

- master branch is the source in markdown for the Jekyll tool.
- asf-site branch is the compiled HTML that is deployed to the webserver.

Part 1 (merging into master): Follow the steps above, but using the rya-site repository to merge the changes from the PR made against the master branch of the rya-site repository into the rya-site master branch

Part 2 (merging into asf-site): If a corresponding PR was made against the asf-site branch, and that PR corresponds to the changes made to master, you can follow the steps similar with Part 1 to merge into asf-site. Be sure that the asf-site matches content in master.  It might be safer to ignore the asf-site pull request and compile the modifications from master as below:

Step 2.0 Install Jekyll if not already installed

Step 2.1 checkout master

git checkout master

Step 2.3 Build the website, test the changes, and compare the result with the current website. Note that different versions of jekyll will generate different structures for the website. If the new website has a different structure than the old, and that was not the intention (for example if a download.html file is created instead of download/index.html), update your version of jeckyll 

cd content/ 
bundle exec jekyll serve 

Step 2.3  Move the content/target folder out of the way, you will commit this separately.

    mv content/target/ ../

Step 2.4 Checkout asf/site, create a new branch, remove old content

git checkout --force origin/asf-site 
    git checkout -b another_new_branch_name_here
    rm -r content

Step 2.5 Now copy the folder formally named target/ into the project, renaming it to content/.

    mv ../target/ ./content

Step 2.6 Use git status to observe changes.  The css and other template files are probably not changed.  If they are flagged as modified, investigate CRLF or other trival differences.  See .gitattributes.  Try git diff  *css.  The file permissions might be different: chmod -R 755 *

Step 2.7  When satisfied that all looks OK, commit changes

    git add [new and modified files]

    git commit -a -m "say what you changed here"

Step 2.8 Merge the changes into asf-site

git checkout asf-site
git merge another_new_branch_name_here

Step 2.9 If there was a PR against the asf-site branch, amend the commit message so that it closes the PR (Github Info here). After running the command below, add the append the following line to the commit "Closes #123 from usrname/branchname".  Note theat "#123" refers to the PR number in GitHub

git commit --amend

Step 2.10 Push changes to Apache asf-site.

git push origin asf-site

Step 2.11: Delete PR branch.

git branch -D another_new_branch_name_here

Closing Stale Issues on Github

Github issues are closed via commit messages to the master branch.  Typically we pull in a PR and close the PR by amending the commit message with the "closes #xxx" line.

But sometimes we need to close a PR without pulling in the PR.  Instead, create an "Empty Commit" and document the reason for the commit in the commit message.

git commit --allow-empty

...

EMPTY COMMIT Closes #110, Closes #109

An Empty Commit to close issues in GitHub

...