http://git-wip-us.apache.org/repos/asf/hbase-site/blob/06efc31c/book.html ---------------------------------------------------------------------- diff --git a/book.html b/book.html index 0b5e82b..e416b41 100644 --- a/book.html +++ b/book.html @@ -13837,7 +13837,7 @@ All options have been discussed separately in the sections above.</p> <span class="comment"><!-- HBase Superuser --></span> <span class="tag"><property></span> <span class="tag"><name></span>hbase.superuser<span class="tag"></name></span> - <span class="tag"><value></span>hbase, admin<span class="tag"></value></span> + <span class="tag"><value></span>hbase,admin<span class="tag"></value></span> <span class="tag"></property></span> <span class="comment"><!-- Coprocessors for ACLs and Visibility Tags --></span> <span class="tag"><property></span> @@ -13857,8 +13857,7 @@ All options have been discussed separately in the sections above.</p> <span class="tag"></property></span> <span class="tag"><property></span> <span class="tag"><name></span>hbase.coprocessor.regionserver.classes<span class="tag"></name></span> - <span class="tag"><value></span>org.apache.hadoop/hbase.security.access.AccessController, - org.apache.hadoop.hbase.security.access.VisibilityController<span class="tag"></value></span> + <span class="tag"><value></span>org.apache.hadoop.hbase.security.access.AccessController<span class="tag"></value></span> <span class="tag"></property></span> <span class="comment"><!-- Executable ACL for Coprocessor Endpoints --></span> <span class="tag"><property></span> @@ -33842,9 +33841,104 @@ This attaches the ReviewBoard to the JIRA, for easy access.</p> <div class="sect3"> <h4 id="_guide_for_hbase_committers"><a class="anchor" href="#_guide_for_hbase_committers"></a>173.7.5. Guide for HBase Committers</h4> <div class="sect4"> +<h5 id="_becoming_a_committer"><a class="anchor" href="#_becoming_a_committer"></a>Becoming a committer</h5> +<div class="paragraph"> +<p>Committers are responsible for reviewing and integrating code changes, testing +and voting on release candidates, weighing in on design discussions, as well as +other types of project contributions. The PMC votes to make a contributor a +committer based on an assessment of their contributions to the project. It is +expected that committers demonstrate a sustained history of high-quality +contributions to the project and community involvement.</p> +</div> +<div class="paragraph"> +<p>Contributions can be made in many ways. There is no single path to becoming a +committer, nor any expected timeline. Submitting features, improvements, and bug +fixes is the most common avenue, but other methods are both recognized and +encouraged (and may be even more important to the health of HBase as a project and a +community). A non-exhaustive list of potential contributions (in no particular +order):</p> +</div> +<div class="ulist"> +<ul> +<li> +<p><a href="#appendix_contributing_to_documentation">Update the documentation</a> for new +changes, best practices, recipes, and other improvements.</p> +</li> +<li> +<p>Keep the website up to date.</p> +</li> +<li> +<p>Perform testing and report the results. For instance, scale testing and +testing non-standard configurations is always appreciated.</p> +</li> +<li> +<p>Maintain the shared Jenkins testing environment and other testing +infrastructure.</p> +</li> +<li> +<p><a href="#hbase.rc.voting">Vote on release candidates</a> after performing validation, even if non-binding. +A non-binding vote is a vote by a non-committer.</p> +</li> +<li> +<p>Provide input for discussion threads on the <a href="/mail-lists.html">mailing lists</a> (which usually have +<code>[DISCUSS]</code> in the subject line).</p> +</li> +<li> +<p>Answer questions questions on the user or developer mailing lists and on +Slack.</p> +</li> +<li> +<p>Make sure the HBase community is a welcoming one and that we adhere to our +<a href="/coc.html">Code of conduct</a>. Alert the PMC if you +have concerns.</p> +</li> +<li> +<p>Review other people’s work (both code and non-code) and provide public +feedback.</p> +</li> +<li> +<p>Report bugs that are found, or file new feature requests.</p> +</li> +<li> +<p>Triage issues and keep JIRA organized. This includes closing stale issues, +labeling new issues, updating metadata, and other tasks as needed.</p> +</li> +<li> +<p>Mentor new contributors of all sorts.</p> +</li> +<li> +<p>Give talks and write blogs about HBase. Add these to the <a href="/">News</a> section +of the website.</p> +</li> +<li> +<p>Provide UX feedback about HBase, the web UI, the CLI, APIs, and the website.</p> +</li> +<li> +<p>Write demo applications and scripts.</p> +</li> +<li> +<p>Help attract and retain a diverse community.</p> +</li> +<li> +<p>Interact with other projects in ways that benefit HBase and those other +projects.</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>Not every individual is able to do all (or even any) of the items on this list. +If you think of other ways to contribute, go for it (and add them to the list). +A pleasant demeanor and willingness to contribute are all you need to make a +positive impact on the HBase project. Invitations to become a committer are the +result of steady interaction with the community over the long term, which builds +trust and recognition.</p> +</div> +</div> +<div class="sect4"> <h5 id="_new_committers"><a class="anchor" href="#_new_committers"></a>New committers</h5> <div class="paragraph"> -<p>New committers are encouraged to first read Apache’s generic committer documentation:</p> +<p>New committers are encouraged to first read Apache’s generic committer +documentation:</p> </div> <div class="ulist"> <ul> @@ -33860,25 +33954,38 @@ This attaches the ReviewBoard to the JIRA, for easy access.</p> <div class="sect4"> <h5 id="_review"><a class="anchor" href="#_review"></a>Review</h5> <div class="paragraph"> -<p>HBase committers should, as often as possible, attempt to review patches submitted by others. -Ideally every submitted patch will get reviewed by a committer <em>within a few days</em>. -If a committer reviews a patch they have not authored, and believe it to be of sufficient quality, then they can commit the patch, otherwise the patch should be cancelled with a clear explanation for why it was rejected.</p> +<p>HBase committers should, as often as possible, attempt to review patches +submitted by others. Ideally every submitted patch will get reviewed by a +committer <em>within a few days</em>. If a committer reviews a patch they have not +authored, and believe it to be of sufficient quality, then they can commit the +patch. Otherwise the patch should be cancelled with a clear explanation for why +it was rejected.</p> </div> <div class="paragraph"> -<p>The list of submitted patches is in the <a href="https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12312392";>HBase Review Queue</a>, which is ordered by time of last modification. -Committers should scan the list from top to bottom, looking for patches that they feel qualified to review and possibly commit.</p> +<p>The list of submitted patches is in the +<a href="https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12312392";>HBase Review Queue</a>, +which is ordered by time of last modification. Committers should scan the list +from top to bottom, looking for patches that they feel qualified to review and +possibly commit. If you see a patch you think someone else is better qualified +to review, you can mention them by username in the JIRA.</p> </div> <div class="paragraph"> -<p>For non-trivial changes, it is required to get another committer to review your own patches before commit. -Use the <b class="button">Submit Patch</b> button in JIRA, just like other contributors, and then wait for a <code>+1</code> response from another committer before committing.</p> +<p>For non-trivial changes, it is required that another committer review your +patches before commit. <strong>Self-commits of non-trivial patches are not allowed.</strong> +Use the <b class="button">Submit Patch</b> button in JIRA, just like other contributors, and +then wait for a <code>+1</code> response from another committer before committing.</p> </div> </div> <div class="sect4"> <h5 id="_reject"><a class="anchor" href="#_reject"></a>Reject</h5> <div class="paragraph"> -<p>Patches which do not adhere to the guidelines in <a href="https://hbase.apache.org/book.html#developer";>HowToContribute</a> and to the <a href="https://wiki.apache.org/hadoop/CodeReviewChecklist";>code review checklist</a> should be rejected. -Committers should always be polite to contributors and try to instruct and encourage them to contribute better patches. -If a committer wishes to improve an unacceptable patch, then it should first be rejected, and a new patch should be attached by the committer for review.</p> +<p>Patches which do not adhere to the guidelines in +<a href="https://hbase.apache.org/book.html#developer";>HowToContribute</a> and to the +<a href="https://wiki.apache.org/hadoop/CodeReviewChecklist";>code review checklist</a> +should be rejected. Committers should always be polite to contributors and try +to instruct and encourage them to contribute better patches. If a committer +wishes to improve an unacceptable patch, then it should first be rejected, and a +new patch should be attached by the committer for further review.</p> </div> </div> <div class="sect4"> @@ -33896,31 +34003,35 @@ If a committer wishes to improve an unacceptable patch, then it should first be <div class="title">Before you commit!!!!</div> <div class="paragraph"> <p>Make sure your local configuration is correct, especially your identity and email. -Examine the output of the $ git config - --list command and be sure it is correct. -See this GitHub article, <a href="https://help.github.com/articles/set-up-git";>Set Up Git</a> if you need pointers.</p> +Examine the output of the $ git config --list command and be sure it is correct. +See <a href="https://help.github.com/articles/set-up-git";>Set Up Git</a> if you need +pointers.</p> </div> </td> </tr> </table> </div> <div class="paragraph"> -<p>When you commit a patch, please:</p> +<p>When you commit a patch:</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> -<p>Include the Jira issue id in the commit message along with a short description of the change. Try -to add something more than just the Jira title so that someone looking at git log doesn’t -have to go to Jira to discern what the change is about. -Be sure to get the issue ID right, as this causes Jira to link to the change in Git (use the -issue’s "All" tab to see these).</p> -</li> -<li> -<p>Commit the patch to a new branch based off master or other intended branch. -It’s a good idea to call this branch by the JIRA ID. -Then check out the relevant target branch where you want to commit, make sure your local branch has all remote changes, by doing a git pull --rebase or another similar command, cherry-pick the change into each relevant branch (such as master), and do git push <remote-server> -<remote-branch>.</p> +<p>Include the Jira issue ID in the commit message along with a short description +of the change. Try to add something more than just the Jira title so that +someone looking at <code>git log</code> output doesn’t have to go to Jira to discern what +the change is about. Be sure to get the issue ID right, because this causes +Jira to link to the change in Git (use the issue’s "All" tab to see these +automatic links).</p> +</li> +<li> +<p>Commit the patch to a new branch based off <code>master</code> or the other intended +branch. It’s a good idea to include the JIRA ID in the name of this branch. +Check out the relevant target branch where you want to commit, and make sure +your local branch has all remote changes, by doing a git pull --rebase or +another similar command. Next, cherry-pick the change into each relevant +branch (such as master), and push the changes to the remote branch using +a command such as git push <remote-server> <remote-branch>.</p> <div class="admonitionblock warning"> <table> <tr> @@ -33937,7 +34048,8 @@ Do not do a git push --force. </div> <div class="paragraph"> <p>Before you can commit a patch, you need to determine how the patch was created. -The instructions and preferences around the way to create patches have changed, and there will be a transition period.</p> +The instructions and preferences around the way to create patches have changed, +and there will be a transition period.</p> </div> <div class="ulist"> <div class="title">Determine How a Patch Was Created</div> @@ -33975,18 +34087,20 @@ below.</p> <div class="title">Example 43. Example of committing a Patch</div> <div class="content"> <div class="paragraph"> -<p>One thing you will notice with these examples is that there are a lot of git pull commands. -The only command that actually writes anything to the remote repository is git push, and you need to make absolutely sure you have the correct versions of everything and don’t have any conflicts before pushing. -The extra git - pull commands are usually redundant, but better safe than sorry.</p> +<p>One thing you will notice with these examples is that there are a lot of +git pull commands. The only command that actually writes anything to the +remote repository is git push, and you need to make absolutely sure you have +the correct versions of everything and don’t have any conflicts before pushing. +The extra git pull commands are usually redundant, but better safe than sorry.</p> </div> <div class="paragraph"> -<p>The first example shows how to apply a patch that was generated with git format-patch and apply it to the <code>master</code> and <code>branch-1</code> branches.</p> +<p>The first example shows how to apply a patch that was generated with git +format-patch and apply it to the <code>master</code> and <code>branch-1</code> branches.</p> </div> <div class="paragraph"> -<p>The directive to use git format-patch rather than git diff, and not to use <code>--no-prefix</code>, is a new one. -See the second example for how to apply a patch created with git - diff, and educate the person who created the patch.</p> +<p>The directive to use git format-patch rather than git diff, and not to use +<code>--no-prefix</code>, is a new one. See the second example for how to apply a patch +created with git diff, and educate the person who created the patch.</p> </div> <div class="listingblock"> <div class="content"> @@ -34010,14 +34124,14 @@ $ git branch -D HBASE-XXXX</pre> </div> </div> <div class="paragraph"> -<p>This example shows how to commit a patch that was created using git diff without <code>--no-prefix</code>. -If the patch was created with <code>--no-prefix</code>, add <code>-p0</code> to the git apply command.</p> +<p>This example shows how to commit a patch that was created using git diff +without <code>--no-prefix</code>. If the patch was created with <code>--no-prefix</code>, add <code>-p0</code> to +the git apply command.</p> </div> <div class="listingblock"> <div class="content"> <pre>$ git apply ~/Downloads/HBASE-XXXX-v2.patch -$ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" --author=<contributor> -a # This -and next command is needed for patches created with 'git diff' +$ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" --author=<contributor> -a # This and next command is needed for patches created with 'git diff' $ git commit --amend --signoff $ git checkout master $ git pull --rebase @@ -34041,7 +34155,9 @@ $ git branch -D HBASE-XXXX</pre> </li> <li> <p>Resolve the issue as fixed, thanking the contributor. -Always set the "Fix Version" at this point, but please only set a single fix version for each branch where the change was committed, the earliest release in that branch in which the change will appear.</p> +Always set the "Fix Version" at this point, but only set a single fix version +for each branch where the change was committed, the earliest release in that +branch in which the change will appear.</p> </li> </ol> </div> @@ -34062,7 +34178,9 @@ The preferred commit message format is:</p> </div> </div> <div class="paragraph"> -<p>If the contributor used git format-patch to generate the patch, their commit message is in their patch and you can use that, but be sure the JIRA ID is at the front of the commit message, even if the contributor left it out.</p> +<p>If the contributor used git format-patch to generate the patch, their commit +message is in their patch and you can use that, but be sure the JIRA ID is at +the front of the commit message, even if the contributor left it out.</p> </div> </div> <div class="sect5"> @@ -41151,7 +41269,7 @@ org/apache/hadoop/hbase/security/access/AccessControlClient.revoke:(Lorg/apache/ <div id="footer"> <div id="footer-text"> Version 3.0.0-SNAPSHOT<br> -Last updated 2018-09-05 14:32:41 UTC +Last updated 2018-09-06 14:33:00 UTC </div> </div> </body>
http://git-wip-us.apache.org/repos/asf/hbase-site/blob/06efc31c/bulk-loads.html ---------------------------------------------------------------------- diff --git a/bulk-loads.html b/bulk-loads.html index daf6361..d55dc11 100644 --- a/bulk-loads.html +++ b/bulk-loads.html @@ -7,7 +7,7 @@ <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> - <meta name="Date-Revision-yyyymmdd" content="20180905" /> + <meta name="Date-Revision-yyyymmdd" content="20180906" /> <meta http-equiv="Content-Language" content="en" /> <title>Apache HBase – Bulk Loads in Apache HBase (TM) @@ -306,7 +306,7 @@ under the License. --> <a href="https://www.apache.org/";>The Apache Software Foundation</a>. All rights reserved. - <li id="publishDate" class="pull-right">Last Published: 2018-09-05</li> + <li id="publishDate" class="pull-right">Last Published: 2018-09-06</li> </p> </div>
