Apache
/
hbase
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HBASE-15910 Update 'Create Patch' in HBase reference guide from make_patch.sh to submit-patch.py. (Apekshit) 

Change-Id: Ifc199ce3e612b8f14f3cc4b6b5f1ada239e5b4db

Signed-off-by: stack <stack@apache.org>
This commit is contained in:
Apekshit 2016-05-28 02:43:34 -07:00 committed by stack
parent 4abc602e3b
commit f2b00e61af
1 changed files with 25 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
src/main/asciidoc/_chapters/developer.adoc
View File

@ -1780,21 +1780,29 @@ It provides a nice overview that applies equally to the Apache HBase Project.
[[submitting.patches.create]] [[submitting.patches.create]]
==== Create Patch ==== Create Patch
The script _dev-support/make_patch.sh_ has been provided to help you adhere to patch-creation guidelines. Use _dev-support/submit-patch.py_ to create patches and optionally, upload to jira and update
The script has the following syntax: reviews on Review Board. Patch name is formatted as (JIRA).(branch name).(patch number).patch to
follow Yetus' naming rules. Use `-h` flag to know detailed usage information. Most useful options
are:
---- . `-b BRANCH, --branch BRANCH` : Specify base branch for generating the diff. If not specified, tracking branch is used. If there is no tracking branch, error will be thrown.
$ make_patch.sh [-a] [-p <patch_dir>] . `-jid JIRA_ID, --jira-id JIRA_ID` : Jira id of the issue. If set, we deduce next patch version from attachments in the jira and also upload the new patch. Script will ask for jira username/password for authentication. If not set, patch is named <branch>.patch.
----
. If you do not pass a `patch_dir`, the script defaults to _~/patches/_. The script builds a new patch, and uses REST API to upload it to the jira (if --jira-id is
If the `patch_dir` does not exist, it is created. specified) and update the review on ReviewBoard (if --skip-review-board not specified).
. By default, if an existing patch exists with the JIRA ID, the version of the new patch is incremented (_HBASE-XXXX-v3.patch_). If the `-a` option is passed, the version is not incremented, but the suffix `-addendum` is added (_HBASE-XXXX-v2-addendum.patch_). A second addendum to a given version is not supported. Remote links in the jira are used to figure out if a review request already exists. If no review
. Detects whether you have more than one local commit on your branch. request is present, then creates a new one and populates all required fields using jira summary,
If you do, the script offers you the chance to run +git rebase patch description, etc. Also adds this review's link to the jira.
-i+ to squash the changes into a single commit so that it can use +git format-patch+.
If you decline, the script uses +git diff+ instead. Authentication::
The patch is saved in a configurable directory and is ready to be attached to your JIRA. Since attaching patches on JIRA and creating/changing review request on ReviewBoard requires a
logged in user, the script will prompt you for username and password. To avoid the hassle every
time, set up `~/.apache-creds` with login details and encrypt it by following the steps in footer
of script's help message.
Python dependencies::
To install required python dependencies, execute
`pip install -r dev-support/python-requirements.txt` from the master branch.
.Patching Workflow .Patching Workflow
@ -1803,21 +1811,12 @@ $ make_patch.sh [-a] [-p <patch_dir>]
* Submit one single patch for a fix. * Submit one single patch for a fix.
If necessary, squash local commits to merge local commits into a single one first. If necessary, squash local commits to merge local commits into a single one first.
See this link:http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash[Stack Overflow question] for more information about squashing commits. See this link:http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash[Stack Overflow question] for more information about squashing commits.
* The patch should have the JIRA ID in the name. * Patch name should be as follows to adhere to Yetus' naming convention.
If you are generating from a branch, include the target branch in the filename.
A common naming scheme for patches is:
+ +
---- ----
HBASE-XXXX.patch (JIRA).(branch name).(patch number).patch
----
+
----
HBASE-XXXX-0.90.patch # to denote that the patch is against branch 0.90
----
+
----
HBASE-XXXX-v3.patch # to denote that this is the third version of the patch
---- ----
For eg. HBASE-11625.master.001.patch, HBASE-XXXXX.branch-1.2.0005.patch, etc.
* To submit a patch, first create it using one of the methods in <<patching.methods,patching.methods>>. * To submit a patch, first create it using one of the methods in <<patching.methods,patching.methods>>.
Next, attach the patch to the JIRA (one patch for the whole fix), using the dialog. Next, attach the patch to the JIRA (one patch for the whole fix), using the dialog.
@ -1831,8 +1830,7 @@ Please understand that not every patch may get committed, and that feedback will
* If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and upload the new one, following the naming conventions in <<submitting.patches.create,submitting.patches.create>>. * If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and upload the new one, following the naming conventions in <<submitting.patches.create,submitting.patches.create>>.
Cancel the Patch Available flag and then re-trigger it, by toggling the btn:[Patch Available] button in JIRA. Cancel the Patch Available flag and then re-trigger it, by toggling the btn:[Patch Available] button in JIRA.
JIRA sorts attached files by the time they were attached, and has no problem with multiple attachments with the same name. JIRA sorts attached files by the time they were attached, and has no problem with multiple attachments with the same name.
However, at times it is easier to refer to different version of a patch if you add `-vX`, where the [replaceable]_X_ is the version (starting with 2). However, at times it is easier to increment patch number in the patch name.
* If you need to submit your patch against multiple branches, rather than just master, name each version of the patch with the branch it is for, following the naming conventions in <<submitting.patches.create,submitting.patches.create>>.
[[patching.methods]] [[patching.methods]]
.Methods to Create Patches .Methods to Create Patches