airavata-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sma...@apache.org
Subject svn commit: r1618633 - in /airavata/site/trunk/content/community: how-to-commit-contributed-code.mdtext how-to-contribute-code.mdtext
Date Mon, 18 Aug 2014 15:33:03 GMT
Author: smarru
Date: Mon Aug 18 15:33:03 2014
New Revision: 1618633

URL: http://svn.apache.org/r1618633
Log:
adding contributor commit guide

Added:
    airavata/site/trunk/content/community/how-to-commit-contributed-code.mdtext
Modified:
    airavata/site/trunk/content/community/how-to-contribute-code.mdtext

Added: airavata/site/trunk/content/community/how-to-commit-contributed-code.mdtext
URL: http://svn.apache.org/viewvc/airavata/site/trunk/content/community/how-to-commit-contributed-code.mdtext?rev=1618633&view=auto
==============================================================================
--- airavata/site/trunk/content/community/how-to-commit-contributed-code.mdtext (added)
+++ airavata/site/trunk/content/community/how-to-commit-contributed-code.mdtext Mon Aug 18
15:33:03 2014
@@ -0,0 +1,57 @@
+Title:     How to Contribute Code to Apache Airavata
+Notice:    Licensed to the Apache Software Foundation (ASF) under one
+           or more contributor license agreements.  See the NOTICE file
+           distributed with this work for additional information
+           regarding copyright ownership.  The ASF licenses this file
+           to you under the Apache License, Version 2.0 (the
+           "License"); you may not use this file except in compliance
+           with the License.  You may obtain a copy of the License at
+           .
+             http://www.apache.org/licenses/LICENSE-2.0
+           .
+           Unless required by applicable law or agreed to in writing,
+           software distributed under the License is distributed on an
+           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+           KIND, either express or implied.  See the License for the
+           specific language governing permissions and limitations
+           under the License.
+
+### Accepting Contributed Code 
+Apache Airavata follows the core philosophy of the Apache Software Foundation, informally
quoted as "Apache Way". To ensure the contributions have both legally complaint as well as
merotically rewarded, following guidlines should be used.
+
+* Prefered contribution is by submitting patches through Airavata JIRA. The contributors
while uploading the PATCH accept the donation of the copy right to ASF. 
+* GitHUB pull requests can be accepted as a developer conveniance, but the individuals should
have a ICLA on file that covers the contributions. When in question, ask on the dev list.

+* Committers accepting the pull requests needs to ensure appropriate credit is given. Merged
committs should annotate to the individual who authored the commit. This is done by ensuing
both name and email addresses are preserved. 
+* Its better to preverse linear commit history and avoiding merged commits. 
+
+Note: This page describes steps for accepting previously contributed code and is relavent
for Airavata committers. Contributors should refer to [Airavata Contributor Guide][airavata-contribute]
+
+
+#### Contributed by a PATCH file
+
+If the contributor has submitted a patch file on mailing list or JIRA (prefered), follow
these steps to commit it.
+
+1. First update your local checkout with any remote changes (git pull).
+ Observe the changes in the patch. Git apply -stat shows the stats about the changes in the
patch. Example: `git apply --stat AIRAVATA-XXXX.patch`
+2. Test if the patch can be seamlessly applied. Example: `git apply --check AIRAVATA-XXXX.patch`
+3. Apply the patch. Use git am instead of git apply so signoff can be used to preserve the
contributor as well as annotated by the committer accepting it. Example: `git am --signoff
< AIRAVATA-XXXX.patch`
+4. Its a good practice to run the full build with test enabled to ensure the patch did not
break the code. 
+5. Finally push the patch to remote master/branch using git push.
+
+#### Contributed by a GitHUB Pull request
+
+Its preferable to clone a new copy into a temporary location (or maintain one for contributions).
This ensures the contributors changes do not get tangled with your local development. The
following steps list out a fresh checkout, adapt them to use your previous checkout. 
+
+1. Clone the Airavata repo:`git clone https://git-wip-us.apache.org/repos/asf/airavata.git`.
`cd airavata` (if the PR is for a branch, do a appropriate checkout)
+2. Configure Airavata GitHUB mirror
+	* If you previously have not done add the github mirror: `git remote add github git@github.com:apache/airavata.git`
+	* Configure to include pull requests: `git config --local --add remote.github.fetch '+refs/pull/*/head:refs/remotes/github/pr/*'`
+	* (optional) you can check out pull requests as a branch and test/review it. Example: `git
checkout github/pr/3`. [Github PR Local checkout][github-pr-checkout] lists this steps in
detail. 
+3. Pick the changes you want to merge from the pull requests: `git cherry-pick hash-to-merge`.
+4. Its a good practice to run the full build with test enabled to ensure the patch did not
break the code.
+5. Finally push the patch to remote master/branch using git push.
+
+[asf-git-instructions]: https://git-wip-us.apache.org/#contents
+[airavata-source]: development/source.html
+[airavata-contribute]: how-to-contribute-code.html
+[github-pr-checkout]: https://help.github.com/articles/checking-out-pull-requests-locally

Modified: airavata/site/trunk/content/community/how-to-contribute-code.mdtext
URL: http://svn.apache.org/viewvc/airavata/site/trunk/content/community/how-to-contribute-code.mdtext?rev=1618633&r1=1618632&r2=1618633&view=diff
==============================================================================
--- airavata/site/trunk/content/community/how-to-contribute-code.mdtext (original)
+++ airavata/site/trunk/content/community/how-to-contribute-code.mdtext Mon Aug 18 15:33:03
2014
@@ -49,11 +49,15 @@ The airavata community will need to revi
 
 During the review process you may be asked to make some changes to your submission. While
working through feedback, it can be beneficial to create new commits so the incremental change
is obvious. This can also lead to a complex set of commits, and having an atomic change per
commit is preferred in the end. Use your best judgement and work with your reviewer as to
when you should revise a commit or create a new one.
 
-A pull request is considered ready to be merged once it gets at lease one +1 from a reviewer.
Once all the changes have been completed and the pull request is accepted, it must be rebased
to the latest upstream version. It is also a good idea to squash all the commits into a single
one, since this will allow us to generate a clean patch and merge it properly.   
+A pull request is considered ready to be merged once it gets at lease one +1 from a reviewer.
Once all the changes have been completed and the pull request is accepted, it must be rebased
to the latest upstream version. It is also a good idea to squash all the commits into a single
one, since this will allow us to generate a clean patch and merge it properly.
+
+#### Accepting Contributions
+Developers with Airavata Commit access should read [Accepting Contribtions][accept-contributions]
on steps to accept the contributed code
 
 [jira]: https://issues.apache.org/jira/browse/airavata
-[checkout]: source.html
+[checkout]: development/source.html
 [setup-git]: https://help.github.com/articles/set-up-git
 [fork-repo]: https://help.github.com/articles/fork-a-repo
 [pull-request]: https://help.github.com/articles/using-pull-requests
 [rebase-branch]: https://help.github.com/articles/about-git-rebase
+[accept-contributions]: how-to-commit-contributed-code.html



Mime
View raw message