Merge pull request #32 from rajitha703/pr
LENS-1541 : Documentation changes for code merge
diff --git a/src/site/apt/developer/commit.apt b/src/site/apt/developer/commit.apt
index 58e6eca..f25c7e9 100644
--- a/src/site/apt/developer/commit.apt
+++ b/src/site/apt/developer/commit.apt
@@ -63,8 +63,9 @@
The list of submitted patches should be ordered by Updated timestamp -
{{{https://issues.apache.org/jira/issues/?jql=project%20%3D%20LENS%20AND%20status%20%3D%20%22Patch%20Available%22%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC} Lens patch available issues}}
- and {{{https://reviews.apache.org/dashboard/?group=lens&view=to-group}Review board}}. Committers should scan the list
- from one which was updated earliest, looking for patches that they feel qualified to review and possibly commit.
+ and {{{https://github.com/apache/lens/pulls?q=is%3Aopen+is%3Apr}Github open pull requests}}. Committers should scan
+ the list from one which was updated earliest, looking for the requests that they feel qualified to review and possibly
+ commit.
Review guidelines are put up at {{{./contribute.html#Review}review guidelines in contributer guide}}
@@ -90,38 +91,7 @@
* Ensure that 24 hours have elapsed since the jira is made patch available or the review request is up. As a practice
we should observe this, but it should be possible to consciously override and commit with a shorter turnaround time.
- * Cross check if your git user.name and user.email are properly configured. Set username and email with commands
-
-+---+
-
-git config user.name "Amareshwari Sriramadasu"
-git config user.email "amareshwari@apache.org"
-
-+---+
-
- * Apply the patch attached on jira. The patch should be licensed under apache license.
-
-+---+
-
- git apply --check lens_patch.patch
- git apply lens_patch.patch
-
-+---+
-
- * Don't forget to do 'git add' on any new files, and 'git rm' on any files that have been 'deleted' by the patch.
-
- * Include the Jira issue id in the commit message, along with a short description of the change and the name of the
- contributor. Be sure to get the issue id right, as this causes Jira to link to the change in git.
-
- * Keep yourself as committer and the contributor as the author of the commit.
-
-+---+
-
- git commit -a --author "Amareshwari Sriramadasu <amareshwari@apache.org>" -m "LENS-123 : Adds awesome feature to lens."
-
-+---+
-
- * Push the commit to master branch
+ * Merge the review/pull request changes to master branch
* Resolve the issue as fixed, thanking the contributor. Always set the "Fix Version" at this point.
diff --git a/src/site/apt/developer/contribute.apt b/src/site/apt/developer/contribute.apt
index 5dbb219..f07e966 100644
--- a/src/site/apt/developer/contribute.apt
+++ b/src/site/apt/developer/contribute.apt
@@ -177,9 +177,9 @@
(through review, suggestions, etc). This also allows scoping the changes in appropriate releases. Code contributions
are to be made available as a patch against a specific JIRA created for the task. Once patches are attached to the
JIRA, the JIRA issue should be marked as "Patch available" by clicking submit. Lens project follows
- RTC (Review then commit). If the change is bigger than a couple of lines of code, contributor should raise a review
- request on review board and attach the patch on jira once review request gets "Ship it" from one of the reviewers.
- It is recommended that large changes are broken up into smaller changes, thus making it
+ RTC (Review then commit). If the change is bigger than a couple of lines of code, contributor should raise a pull
+ request with the changes, for review on github and attach the patch on jira once pull request gets "Ship it" from one
+ of the reviewers. It is recommended that large changes are broken up into smaller changes, thus making it
easy for review. The patches should comply with the requirements below before they are made available for review.
** Code compliance
@@ -332,102 +332,28 @@
+---+
-** Review request
+** Review/Pull request
- Install reviewboard command line tool:
-
- * Make sure you have python installed and easy_install is available.
-
- * $ easy_install -U setuptools
-
- * More help available at {{{https://www.reviewboard.org/docs/rbtools/dev/}Reviewboard Documentation}}.
-
-
-*** Posting a review request
-
- Whenever you want to publish a new review request, commit all the changes you want to send to the request and do:
-
-+---+
-
- rbt post --parent=master
-
-+---+
- Reviewboard is not foolproof. Sometimes this will create a review request but wouldn't attach the patch. In that case,
- you have to manually create the patch and upload it to the url of the request. To create the patch:
-
-+---+
-
- git diff master..HEAD > ~/LENS-##.patch
-
-+---+
-
- For updating an existing review request:
-
-+---+
-
- rbt post -u --parent=master
-
-+---+
-
- Any changes you make from the command line to the review request are not published. They are only submitted as a
- draft. So the second step would be to open the review request url and update the necessary info like Title, Reviewer,
- Bug number etc.
-
-*** After the patch is merged
-
- After merge, make sure you close the review request by either clicking close on the request's URL or by command line:
-
-+---+
-
- rbt close --close-type={submitted/discarded} #####(request id)
-
-+---+
-
- But it won't be merged until you follow one more step:
-
-** Submit patch
-
- After the patch is reviewed on review board and validated by committers, they will post a "Ship It!" review.
- After that, you're expected to take the patch from reviewboard, attach it on the jira and make the jira "Patch Available".
- Only after that's done, will it be committed.
-
-** Unifying the above
-
- So The above steps can get time consuming after few times. We recommend you use the above steps at least a few times
- to understand and internalize the process. There is also an automated way of doing the above things. One of the lens
- developers has developed a command line tool for it. It's available at
- {{{https://github.com/prongs/rbt-jira}https://github.com/prongs/rbt-jira}}.
- The typical contributor workflow will be like following:
+ Whenever you want to publish a new review/pull request, please follow below steps :
* Make Changes
- * Generate patch using git diff
+ * Commit the changes on Github. Raise a pull request from your local repository branch to apache lens master branch.
- * Post patch to reviewboard.
+ * Format commit messages and pull request title like "LENS-XXX : Test changes", where LENS-XXX corresponds to the jira
+ id. This will automatically link the pull request to the issue.
* Review Happens
- * Go back to step 1 to make changes according to the review. Or go to next step if Ship It! is provided
-
- * Download patch from review board
-
- * Attach patch in jira
-
- * Make jira patch available
-
- * Still a review can cause the patch to be cancelled. Go back to step 1. Or next step if it's committed.
+ * Go back to step 1 based on review. Or go to next step if an approval is provided
* Done.
-
- So there's multiple steps involved in loops. The rbt-jira tool aims to automate precisely them. The documentation of
- the tool you can check on it's own github, as it's still in development and is subject to change.
-
* Quality improvements
Here are some guidelines for contributing to Apache Lens, to improve quality of the project
- * Actively look at {{{https://reviews.apache.org/dashboard/?group=lens&view=to-group}Review board}} and
+ * Actively look at {{{https://github.com/apache/lens/pulls?q=is%3Aopen+is%3Apr}Github open pull requests}} and
{{{https://issues.apache.org/jira/issues/?jql=project%20%3D%20LENS%20AND%20status%20%3D%20%22Patch%20Available%22%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC} Patch available queue}}
on lens and check the issues if they are verifiable, by looking for the following
@@ -567,11 +493,10 @@
* Review
- Lens uses {{{https://reviews.apache.org/dashboard/?group=lens&view=to-group}Review board}} for review requests. If
- you are interested in reviewing in changes put by other contributors actively look at the review board for requests
- put up
+ Lens use github pull requests to merge code. If you are interested in reviewing the changes put by other contributors
+ actively look at the open pull requests put up on Github.
- Some things that are important to check for in patches/review requests
+ Some things that are important to check for in review/pull requests
* Code style as per {{{./contribute.html#Code_compliance}coding guidelines in contributer guide}}
