Fixed: HBase Generate Website

[Apache Jenkins Server]

Build status: Fixed

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/526/artifact/website.patch.zip
 | funzip > a41b1852da5d445f711237afaf5a58f26998ed6b.patch
  git fetch
  git checkout -b asf-site-a41b1852da5d445f711237afaf5a58f26998ed6b 
origin/asf-site
  git am --whitespace=fix a41b1852da5d445f711237afaf5a58f26998ed6b.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-a41b1852da5d445f711237afaf5a58f26998ed6b branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-a41b1852da5d445f711237afaf5a58f26998ed6b:asf-site
  git checkout asf-site
  git branch -D asf-site-a41b1852da5d445f711237afaf5a58f26998ed6b

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/526/console

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

[Sean Busbey]

It's only been 8 hours Ted, let's wait a bit to make sure folks have a
chance to contribute to the discussion if they like.

On Mar 20, 2017 4:28 PM, "Ted Yu"  wrote:

Sean:
Can you log a JIRA so that we can move this forward ?

Cheers

On Mon, Mar 20, 2017 at 2:20 PM, Josh Elser  wrote:

> Sean Busbey wrote:
>
>> On Mon, Mar 20, 2017 at 11:09 AM, Ted Yu  wrote:
>>
>>> Is Yetus 0.4.0 release stable ?
>>>
>>>
>> yes.
>>
>>
>> If we use Yetus annotations, is there only one jar pulled in as
>>> dependency ?
>>>
>>>
>> IIRC, we'll get one jar as a dependency. There shouldn't be any
>> transitive dependencies involved.
>>
>
> Less code in HBase? No extra "cruft" coming in?
>
> Sign me up!
>

Re: Failure: HBase Generate Website

[Dima Spivak]

Looks like we have a hanging tag on the resources page, Stack. Can you take
a look?

On Mon, Mar 20, 2017 at 12:13 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

Build status: Failure

If successful, the website and docs have been generated. To update the live
site, follow the instructions below. If failed, skip to the bottom of this
email.

Use the following commands to download the patch and apply it to a clean
branch based on origin/asf-site. If you prefer to keep the hbase-site repo
around permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O-
https://builds.apache.org/job/hbase_generate_website/525/artifact/website.patch.zip
| funzip > ${GIT_SHA}.patch
  git fetch
  git checkout -b asf-site-${GIT_SHA} origin/asf-site
  git am --whitespace=fix $GIT_SHA.patch

At this point, you can preview the changes by opening index.html or any of
the other HTML pages in your local asf-site-${GIT_SHA} branch.

There are lots of spurious changes, such as timestamps and CSS styles in
tables, so a generic git diff is not very useful. To see a list of files
that have been added, deleted, renamed, changed type, or are otherwise
interesting, use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF
INFRA bug
  git push origin asf-site-${GIT_SHA}:asf-site
  git checkout asf-site
  git branch -D asf-site-${GIT_SHA}

Changes take a couple of minutes to be propagated. You can verify whether
they have been propagated by looking at the Last Published date at the
bottom of http://hbase.apache.org/. It should match the date in the
index.html on the asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you
pushed the site.



If failed, see
https://builds.apache.org/job/hbase_generate_website/525/console

-- 
-Dima

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

[Josh Elser]

Sean Busbey wrote:

On Mon, Mar 20, 2017 at 11:09 AM, Ted Yu  wrote:

Is Yetus 0.4.0 release stable ?



yes.



If we use Yetus annotations, is there only one jar pulled in as dependency ?



IIRC, we'll get one jar as a dependency. There shouldn't be any
transitive dependencies involved.


Less code in HBase? No extra "cruft" coming in?

Sign me up!

Re: Multiple match's Filter is NOT WORKING

[Josh Elser]

If you could encapsulate what you're trying to do into a 
unit-test/standalone class, it would likely be much more approachable 
for anyone to reproduce and help debug your issues.


You've provided a lot of information, but very little of it is helpful 
in actually figuring out why what you've done doesn't work. Most of the 
time, the devil is in the details which your code snippets wouldn't 
capture in the first place.


Please do remember that we're all volunteers. We want to try to help, 
but you'll get a much better response with the carrot (effort from your 
side to show what doesn't work) than the stick (threatening to "give up 
using HBase").


Yoom Nguyen wrote:

Would anyone know if this is the right forum to ask this type of question? If 
not, would you suggest where I should try to ask this type of question before I 
am giving up using HBASE all together.
I am stuck for a while now and not able to get any advice from anyone.

Thanks in advance,
Yoom

- Original Message -

From: "Yoom Nguyen"
To: dev@hbase.apache.org
Sent: Sunday, March 19, 2017 5:46:17 PM
Subject: Multiple match's Filter is NOT WORKING


I am having problems getting correct match's results from searching through 
multiple HBASE's tables.
Is there a bug in HBASE's filter? Wondering if anyone know HBASE \ Java well 
and willing to help out or for a fee.
Is this a bug with HBASE?

HBASE Release 0.98.8 - 11/18/2014


Would someone help me out with the problem or confirmation whether HBASE is the 
right tool or not.

Here are the details of the problem:
First I am reading some data from one table and storing in a vector or 
arrayList: Is there a better way or different approach to achieve the results 
than what I am heading? I am stuck trying to get the correct results with the 
following approach.

//First, I am reading some data from one table and storing in a vector or 
arrayList:

for (Result r : rs) {
for (KeyValue kv : r.raw()) {
if (new String(kv.getFamily()).equals("name")) {
temp = new String(kv.getValue());
x.addElement(temp);
}
}
}


//Then, I want to search a different table based on the values of this vector.
//I used filters to do this: (I tried BinaryPrefixComparator and 
BinaryComparator as well)


FilterList filterList = new FilterList(FilterList.Operator.MUST_PASS_ONE);

for (int c = 0; c<  x.size(); c++) {
System.out.println(x.get(c).toString());
filterList.addFilter(new SingleColumnValueFilter(Bytes.toBytes("name"), null,
CompareOp.EQUAL, new SubstringComparator( x.get(c).toString() )));
}

//I should get 3 results back, however I only get one result back, the first 
entry in the database.
What doesn't make sense is that when I hardcode the value that I am looking for 
into my code, I will get all 3 results back.

I thought there might be some issue with converting the bytes to String and 
then back to bytes, but that would not explain how it was able to bring back 
the first result. For some reason, it is stopping at the first match and 
doesn't continue to find the other 2 rows that contain matching data. If I 
hardcode it i get the results:


x.addElement("abc123");
filterList.addFilter(new SingleColumnValueFilter(Bytes.toBytes("mpnum"), null, 
CompareOp.EQUAL, new SubstringComparator( x.get(0).toString() )));


edit: Here is the contents of the tables:

TABLE1: ROW COLUMN+CELL
0 column=gpnum:, timestamp=1481300288449, value=def123
0 column=mpnum:, timestamp=1481300273355, value=abc123
0 column=price:, timestamp=1481300255337, value=85.0
1 column=gpnum:, timestamp=148130159, value=def2244
1 column=mpnum:, timestamp=1481301582336, value=011511607
1 column=price:, timestamp=1481301673886, value=0.76

TABLE2

ROW COLUMN+CELL
0 column=brand:, timestamp=1481300227283, value=x
0 column=mpnum:, timestamp=1481300212289, value=abc123
0 column=price:, timestamp=1481300110950, value=50.0
1 column=mpnum:, timestamp=1481301806687 , value=011511607
1 column=price:, timestamp=1481301777345 , value=1.81
13 column=webtype:, timestamp=1483507543878, value=US
3 column=avail:, timestamp=1481306538360, value=avail
3 column=brand:, timestamp=1481306538360, value=brand
3 column=descr:, timestamp=1481306538360, value=description
3 column=dist:, timestamp=1481306538360, value=distributor
3 column=mpnum:, timestamp=1481306538360, value=pnum
3 column=price:, timestamp=1481306538360, value=price
3 column=url:, timestamp=1481306538360, value=url
3 column=webtype:, timestamp=1481306538360, value=webtype
4 column=avail:, timestamp=1481306538374, value=4
4 column=brand:, timestamp=1481306538374, value=x
4 column=descr:, timestamp=1481306538374, value=description
4 column=dist:, timestamp=1481306538374, value=x
4 column=mpnum:, timestamp=1482117383212 , value=011511607
4 column=price:, timestamp=1481306538374 , value=34.51
4 column=url:, timestamp=1481306538374, value=x:q!
4 column=webtype:, timestamp=1481306538374, value=US
5 column=avail:, timestamp=1481306538378, value=
5 column=brand:, 

Re: About the InterfaceStability annotation for public API

[Jerry He]

Just to bring up an alternative idea.
The Spark InterfaceStability explicitly spells out what can or can not
change from major or minor releases. (I was onto it recently).
See [1]

HBase is probably a more stable project that does not have to do the same.
But it is also possible that we may have new features (i.e. AsyncClient,
Backup, etc) that we want to evolve within a major release.
We should see if we want to provide such flexibility via the
InterfaceStability annotations and document it explicitly if yes.

Thanks,

Jerry


1. https://github.com/apache/spark/blob/master/common/tags/
src/main/java/org/apache/spark/annotation/InterfaceStability.java




On Mon, Mar 20, 2017 at 10:46 AM, Yu Li  wrote:

> +1 on removing InterfaceStability annotation for IA.Public. Even more, is
> it possible to forbid using these two annotations together in Yetus at
> code-level if we are migrating to it (as mentioned in another thread)?
>
> For IA.Private or IA.LimitedPrivate, personally I think InterfaceStability
> is still a useful annotation.
>
> Best Regards,
> Yu
>
> On 20 March 2017 at 22:07, Sean Busbey  wrote:
>
> > I really dislike having InterfaceStability markings on IA.Public
> > interfaces, because to me it reads like us essentially saying we
> > didn't invest enough time in deciding what something should look like
> > before declaring it safe for downstream folks. If someone is
> > comfortable with the risk of an API that can change in minor or
> > maintenance releases, what's gained by calling it IA.Public +
> > IS.Evolving or Unstable rather than just labeling it IA.Private or
> > IA.LimitedPrivate?
> >
> > So I'd be +1 on updating our docs to state that InterfaceStability is
> > just for IA.LimitedPrivate or even discontinuing our use of it
> > entirely.
> >
> > On Sun, Mar 19, 2017 at 11:28 PM, Duo Zhang  wrote:
> > > In the compatibility section of our refguide, the compatibility for
> patch
> > > version, minor version and major version is not related
> > > to InterfaceStability annotation. The only place we mention it is for
> > > Server-Side Limited API compatibility.
> > >
> > > And  in the Developer Guidelines section, we say this
> > > @InterfaceStability.Evolving
> > >
> > > Public packages marked as evolving may be changed, but it is
> discouraged.
> > > I think this is a little confusing, esepecially that the comment
> > > of InterfaceStability also mentions the compatibility for patch, minor
> > and
> > > major release.
> > >
> > > For me, I think only InterfaceStability.Unstable is useful for public
> > API.
> > > It means the API is still experimental and will not respect the
> > > compatibility rule.
> > >
> > > So here I suggest we just remove the InterfaceStability annoation for
> the
> > > classes which are marked as InterfaceAudience.Public, and change the
> > > comment of InterfaceStability and also the refguide to be more
> specific.
> > >
> > > Suggestions are welcomed.
> > >
> > > Thanks.
> >
>

[jira] [Resolved] (HBASE-17811) TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in "branch-1"

[Josh Elser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser resolved HBASE-17811.

Resolution: Invalid

> TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in 
> "branch-1"
> --
>
> Key: HBASE-17811
> URL: https://issues.apache.org/jira/browse/HBASE-17811
> Project: HBase
>  Issue Type: Bug
>  Components: Thrift
>Affects Versions: 2.0.0
> Environment: OS: Ubuntu 14.04
> Arch:x86_64
>Reporter: Anup Halarnkar
> Fix For: 2.0.0
>
>
> Module Thrift fails with this output:
> Results :
> Failed tests:
>   TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength
> Expected: (an instance of org.apache.thrift.transport.TTransportException and 
> exception with message a string containing "HTTP Response code: 413")
>  but: exception with message a string containing "HTTP Response code: 
> 413" message was "java.net.ConnectException: Connection refused (Connection 
> refused)"
> Stacktrace was: org.apache.thrift.transport.TTransportException: 
> java.net.ConnectException: Connection refused (Connection refused)
> at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:356)
> at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:73)
> at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62)
> at 
> org.apache.hadoop.hbase.thrift.generated.Hbase$Client.send_getTableNames(Hbase.java:901)
> at 
> org.apache.hadoop.hbase.thrift.generated.Hbase$Client.getTableNames(Hbase.java:894)
> at 
> org.apache.hadoop.hbase.thrift.TestThriftServer.checkTableList(TestThriftServer.java:248)
> at 
> org.apache.hadoop.hbase.thrift.TestThriftHttpServer.talkToThriftServer(TestThriftHttpServer.java:187)
> at 
> org.apache.hadoop.hbase.thrift.TestThriftHttpServer.runThriftServer(TestThriftHttpServer.java:147)
> at 
> org.apache.hadoop.hbase.thrift.TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength(TestThriftHttpServer.java:121)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
> at sun.net.www.http.HttpClient.(HttpClient.java:211)
> at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> at 
> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1202)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1138)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1032)
> at 
> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:966)
> at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:344)
> ... 20 more
> Tests run: 88, Failures: 1, Errors: 0, Skipped: 0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17813) backport HBASE-16983 to branch-1.3

[Yu Li (JIRA)]

Yu Li created HBASE-17813:
-

 Summary: backport HBASE-16983 to branch-1.3
 Key: HBASE-17813
 URL: https://issues.apache.org/jira/browse/HBASE-17813
 Project: HBase
  Issue Type: Bug
Reporter: Yu Li
Assignee: Yu Li


>From [recent UT 
>report|https://builds.apache.org/job/PreCommit-HBASE-Build/6170/testReport/] 
>of branch-1.3, we could see the same issue "Unable to create region 
>directory..." as described by HBASE-16983, so we should backport the JIRA to 
>fix this intermittent failure and avoid it blocking new commits.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] First release candidate for HBase 1.2.5 is available

[Andrew Purtell]

Thanks Josh. Appreciate the release vote, let's do this again. :-)

On Mon, Mar 20, 2017 at 2:21 PM, Josh Elser  wrote:

> Please do. Thanks for checking.
>
> +1 (binding)
>
>
> Sean Busbey wrote:
>
>> Hi Josh!
>>
>> Are you comfortable with me considering your vote binding now that
>> you're a PMC member?
>>
>> On Sat, Mar 11, 2017 at 5:24 PM, Josh Elser  wrote:
>>
>>> +1 (non-binding)
>>>
>>> * xsums/sigs OK
>>> * Compat report looks OK for a patch release
>>> * Spot-checked source release and ran apache-rat:check
>>> * Can build from source (and run a subset of tests)
>>> * KEYS has the signing key
>>> * Commit is in source repository
>>>
>>>
>>> Sean Busbey wrote:
>>>
 The first release candidate for HBase 1.2.5 is available for download
 at:

 https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/

 Maven artifacts are also available in a staging repository at:

 https://repository.apache.org/content/repositories/orgapachehbase-1164/

 Artifacts are signed with my key (0D80DB7C) published in our KEYS
 file at http://www.apache.org/dist/hbase/KEYS

 The RC corresponds to the signed tag 1.2.5RC0, which currently points
 to commit ref

 d7b05f79dee10e0ada614765bb354b93d615a157

 The detailed source and binary compatibility report vs 1.2.4 has been
 published for your review, at:


 https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
 1.2.4_1.2.5RC0_compat_report.html

 Note that this report calls out the issue discussed in HBASE-17725.

 HBase 1.2.5 is the fifth maintenance release in the HBase 1.2 line,
 continuing on
 the theme of bringing a stable, reliable database to the Hadoop and
 NoSQL
 communities. This release includes over 50 bug fixes since 1.2.4.
 Critical fixes include:

 * HBASE-17069 RegionServer writes invalid META entries for split
 daughters in some circumstances
 * HBASE-17044 Fix merge failed before creating merged region leaves
 meta inconsistent
 * HBASE-17206 FSHLog may roll a new writer successfully with unflushed
 entries
 * HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
 spread of regions for small tables.


 The full list of fixes included in this release is available at:


 https://issues.apache.org/jira/secure/ReleaseNote.jspa?versi
 on=12338339=12310753

 and in the CHANGES.txt file included in the distribution.

 Please try out this candidate and vote +1/-1 on whether we should
 release these artifacts as HBase 1.2.5.

 The VOTE will remain open for atleast 72 hours. Given sufficient votes
 I would like to close it on March 17th, 2017.

 thanks!

>>>


-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

Re: [DISCUSS] Moving towards merge on HBASE-16961 (space quota)

[Josh Elser]

Rebase is done for those who want to just look at some code.

https://github.com/apache/hbase/compare/HBASE-16961

Josh Elser wrote:

Hiya folks,

As advertised (warned? *winks*), all of the sub-tasks on HBASE-16961
have been resolved after being committed to the HBASE-16961 branch in SCM.

While Ted has been a stalwart reviewer, it would be good to get another
set of eyes (or a few sets) on the changes before considering I start a
vote to merge into master.

Presently, I'm rebasing the branch on top of master (as it's been a
while since I've done that). While I do that, I wanted to ask: what can
I do to help make this review process easiest?

* Squash commits into one and put on RB?
* Pointers to tests that outline how users interact via API?
* Put together a little example devs can work through locally?

I want to avoid this work lingering in the ether for a long period of
time -- I'm happy to try to make what will surely be a difficult review
any easier.

- Josh

[jira] [Created] (HBASE-17807) correct the value of zookeeper.session.timeout in hbase doc

[Yechao Chen (JIRA)]

Yechao Chen created HBASE-17807:
---

 Summary: correct the value of zookeeper.session.timeout in hbase 
doc
 Key: HBASE-17807
 URL: https://issues.apache.org/jira/browse/HBASE-17807
 Project: HBase
  Issue Type: Bug
Reporter: Yechao Chen
Assignee: Yechao Chen
Priority: Trivial


I met a regionserver gc problem, and the regionserver log show me to read the 
doc
http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired

If you wish to increase the session timeout, add the following to your 
hbase-site.xml to increase the timeout from the default of 60 seconds to 120 
seconds.


  zookeeper.session.timeout
  120


the value should be 12（120s) instead of 120(1200s）



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[DISCUSS] Moving towards merge on HBASE-16961 (space quota)

[Josh Elser]

Hiya folks,

As advertised (warned? *winks*), all of the sub-tasks on HBASE-16961 
have been resolved after being committed to the HBASE-16961 branch in SCM.


While Ted has been a stalwart reviewer, it would be good to get another 
set of eyes (or a few sets) on the changes before considering I start a 
vote to merge into master.


Presently, I'm rebasing the branch on top of master (as it's been a 
while since I've done that). While I do that, I wanted to ask: what can 
I do to help make this review process easiest?


* Squash commits into one and put on RB?
* Pointers to tests that outline how users interact via API?
* Put together a little example devs can work through locally?

I want to avoid this work lingering in the ether for a long period of 
time -- I'm happy to try to make what will surely be a difficult review 
any easier.


- Josh

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

[Ted Yu]

Sean:
Can you log a JIRA so that we can move this forward ?

Cheers

On Mon, Mar 20, 2017 at 2:20 PM, Josh Elser  wrote:

> Sean Busbey wrote:
>
>> On Mon, Mar 20, 2017 at 11:09 AM, Ted Yu  wrote:
>>
>>> Is Yetus 0.4.0 release stable ?
>>>
>>>
>> yes.
>>
>>
>> If we use Yetus annotations, is there only one jar pulled in as
>>> dependency ?
>>>
>>>
>> IIRC, we'll get one jar as a dependency. There shouldn't be any
>> transitive dependencies involved.
>>
>
> Less code in HBase? No extra "cruft" coming in?
>
> Sign me up!
>

Re: [ANNOUNCE] New HBase committer Chia-Ping Tsai

[Enis Söztutar]

Congrats and welcome!

Enis

On Mon, Mar 20, 2017 at 10:16 AM, ramkrishna vasudevan <
ramkrishna.s.vasude...@gmail.com> wrote:

> Congratulations !!!
>
> On Mon, Mar 20, 2017 at 10:43 PM, Huaxiang Sun  wrote:
>
> > Congratulations, Chia-Ping!
> >
> > > On Mar 18, 2017, at 5:38 AM, Ashish Singhi  > com> wrote:
> > >
> > > Many Congratulations !
> > >
> > > On Sat, Mar 18, 2017 at 4:00 AM, Anoop John 
> > wrote:
> > >
> > >> On behalf of the Apache HBase PMC, I am pleased to announce that
> > Chia-Ping
> > >> Tsai
> > >> has accepted the PMC's invitation to become a committer on the
> project.
> > We
> > >> appreciate all of his contributions thus far and look forward
> > >> to his continued involvement.
> > >>
> > >> Congratulation and welcome Chia-Ping Tsai!
> > >>
> > >> -Anoop-
> > >>
> >
> >
>

Re: Failure: HBase Generate Website

[Stack]

Yes. My fault. Thanks for the kick Dima.
St.Ack

On Mon, Mar 20, 2017 at 1:52 PM, Dima Spivak  wrote:

> Looks like we have a hanging tag on the resources page, Stack. Can you take
> a look?
>
> On Mon, Mar 20, 2017 at 12:13 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> Build status: Failure
>
> If successful, the website and docs have been generated. To update the live
> site, follow the instructions below. If failed, skip to the bottom of this
> email.
>
> Use the following commands to download the patch and apply it to a clean
> branch based on origin/asf-site. If you prefer to keep the hbase-site repo
> around permanently, you can skip the clone step.
>
>   git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
>
>   cd hbase-site
>   wget -O-
> https://builds.apache.org/job/hbase_generate_website/525/
> artifact/website.patch.zip
> | funzip > ${GIT_SHA}.patch
>   git fetch
>   git checkout -b asf-site-${GIT_SHA} origin/asf-site
>   git am --whitespace=fix $GIT_SHA.patch
>
> At this point, you can preview the changes by opening index.html or any of
> the other HTML pages in your local asf-site-${GIT_SHA} branch.
>
> There are lots of spurious changes, such as timestamps and CSS styles in
> tables, so a generic git diff is not very useful. To see a list of files
> that have been added, deleted, renamed, changed type, or are otherwise
> interesting, use the following command:
>
>   git diff --name-status --diff-filter=ADCRTXUB origin/asf-site
>
> To see only files that had 100 or more lines changed:
>
>   git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'
>
> When you are satisfied, publish your changes to origin/asf-site using these
> commands:
>
>   git commit --allow-empty -m "Empty commit" # to work around a current ASF
> INFRA bug
>   git push origin asf-site-${GIT_SHA}:asf-site
>   git checkout asf-site
>   git branch -D asf-site-${GIT_SHA}
>
> Changes take a couple of minutes to be propagated. You can verify whether
> they have been propagated by looking at the Last Published date at the
> bottom of http://hbase.apache.org/. It should match the date in the
> index.html on the asf-site branch in Git.
>
> As a courtesy- reply-all to this email to let other committers know you
> pushed the site.
>
>
>
> If failed, see
> https://builds.apache.org/job/hbase_generate_website/525/console
>
> --
> -Dima
>

Re: [VOTE] First release candidate for HBase 1.2.5 is available

[Josh Elser]

Please do. Thanks for checking.

+1 (binding)

Sean Busbey wrote:

Hi Josh!

Are you comfortable with me considering your vote binding now that
you're a PMC member?

On Sat, Mar 11, 2017 at 5:24 PM, Josh Elser  wrote:

+1 (non-binding)

* xsums/sigs OK
* Compat report looks OK for a patch release
* Spot-checked source release and ran apache-rat:check
* Can build from source (and run a subset of tests)
* KEYS has the signing key
* Commit is in source repository


Sean Busbey wrote:

The first release candidate for HBase 1.2.5 is available for download at:

https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/

Maven artifacts are also available in a staging repository at:

https://repository.apache.org/content/repositories/orgapachehbase-1164/

Artifacts are signed with my key (0D80DB7C) published in our KEYS
file at http://www.apache.org/dist/hbase/KEYS

The RC corresponds to the signed tag 1.2.5RC0, which currently points
to commit ref

d7b05f79dee10e0ada614765bb354b93d615a157

The detailed source and binary compatibility report vs 1.2.4 has been
published for your review, at:


https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/1.2.4_1.2.5RC0_compat_report.html

Note that this report calls out the issue discussed in HBASE-17725.

HBase 1.2.5 is the fifth maintenance release in the HBase 1.2 line,
continuing on
the theme of bringing a stable, reliable database to the Hadoop and NoSQL
communities. This release includes over 50 bug fixes since 1.2.4.
Critical fixes include:

* HBASE-17069 RegionServer writes invalid META entries for split
daughters in some circumstances
* HBASE-17044 Fix merge failed before creating merged region leaves
meta inconsistent
* HBASE-17206 FSHLog may roll a new writer successfully with unflushed
entries
* HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
spread of regions for small tables.


The full list of fixes included in this release is available at:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338339=12310753

and in the CHANGES.txt file included in the distribution.

Please try out this candidate and vote +1/-1 on whether we should
release these artifacts as HBase 1.2.5.

The VOTE will remain open for atleast 72 hours. Given sufficient votes
I would like to close it on March 17th, 2017.

thanks!

[jira] [Created] (HBASE-17814) Move hbasecon site to hbase.apache.org

[stack (JIRA)]

stack created HBASE-17814:
-

 Summary: Move hbasecon site to hbase.apache.org
 Key: HBASE-17814
 URL: https://issues.apache.org/jira/browse/HBASE-17814
 Project: HBase
  Issue Type: Bug
Reporter: stack


Moving our hbasecon pages from a site that Cloudera sponsored.

We want to be able to point hbasecon our new hosts for this year (and keep 
around links to the old content which while it is all up on youtube and 
slideshare, the hbasecon archive pages have the pointers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [ANNOUNCE] New HBase committer Chia-Ping Tsai

[Nick Dimiduk]

Nice work and congratulations!

On Fri, Mar 17, 2017 at 3:30 PM, Anoop John  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Chia-Ping
> Tsai
> has accepted the PMC's invitation to become a committer on the project. We
> appreciate all of his contributions thus far and look forward
> to his continued involvement.
>
> Congratulation and welcome Chia-Ping Tsai!
>
> -Anoop-
>

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/528/artifact/website.patch.zip
 | funzip > cc59fe4e91ab0099f65566bc90e77e37f8147119.patch
  git fetch
  git checkout -b asf-site-cc59fe4e91ab0099f65566bc90e77e37f8147119 
origin/asf-site
  git am --whitespace=fix cc59fe4e91ab0099f65566bc90e77e37f8147119.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-cc59fe4e91ab0099f65566bc90e77e37f8147119 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-cc59fe4e91ab0099f65566bc90e77e37f8147119:asf-site
  git checkout asf-site
  git branch -D asf-site-cc59fe4e91ab0099f65566bc90e77e37f8147119

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/528/console

Re: About the InterfaceStability annotation for public API

[Duo Zhang]

bq.  If someone is
comfortable with the risk of an API that can change in minor or
maintenance releases, what's gained by calling it IA.Public +
IS.Evolving or Unstable rather than just labeling it IA.Private or
IA.LimitedPrivate?

Indeed. We can not stop users use IA.Private classes if they are declared
as public class. The users take the risk by themselves.

Anyway, seems we all agree that at least we need to update our
documentation. So let me open a issue first. We can continue the discussion
there.

Thanks.

2017-03-21 4:27 GMT+08:00 Jerry He :

> Just to bring up an alternative idea.
> The Spark InterfaceStability explicitly spells out what can or can not
> change from major or minor releases. (I was onto it recently).
> See [1]
>
> HBase is probably a more stable project that does not have to do the same.
> But it is also possible that we may have new features (i.e. AsyncClient,
> Backup, etc) that we want to evolve within a major release.
> We should see if we want to provide such flexibility via the
> InterfaceStability annotations and document it explicitly if yes.
>
> Thanks,
>
> Jerry
>
>
> 1. https://github.com/apache/spark/blob/master/common/tags/
> src/main/java/org/apache/spark/annotation/InterfaceStability.java
>
>
>
>
> On Mon, Mar 20, 2017 at 10:46 AM, Yu Li  wrote:
>
> > +1 on removing InterfaceStability annotation for IA.Public. Even more, is
> > it possible to forbid using these two annotations together in Yetus at
> > code-level if we are migrating to it (as mentioned in another thread)?
> >
> > For IA.Private or IA.LimitedPrivate, personally I think
> InterfaceStability
> > is still a useful annotation.
> >
> > Best Regards,
> > Yu
> >
> > On 20 March 2017 at 22:07, Sean Busbey  wrote:
> >
> > > I really dislike having InterfaceStability markings on IA.Public
> > > interfaces, because to me it reads like us essentially saying we
> > > didn't invest enough time in deciding what something should look like
> > > before declaring it safe for downstream folks. If someone is
> > > comfortable with the risk of an API that can change in minor or
> > > maintenance releases, what's gained by calling it IA.Public +
> > > IS.Evolving or Unstable rather than just labeling it IA.Private or
> > > IA.LimitedPrivate?
> > >
> > > So I'd be +1 on updating our docs to state that InterfaceStability is
> > > just for IA.LimitedPrivate or even discontinuing our use of it
> > > entirely.
> > >
> > > On Sun, Mar 19, 2017 at 11:28 PM, Duo Zhang 
> wrote:
> > > > In the compatibility section of our refguide, the compatibility for
> > patch
> > > > version, minor version and major version is not related
> > > > to InterfaceStability annotation. The only place we mention it is for
> > > > Server-Side Limited API compatibility.
> > > >
> > > > And  in the Developer Guidelines section, we say this
> > > > @InterfaceStability.Evolving
> > > >
> > > > Public packages marked as evolving may be changed, but it is
> > discouraged.
> > > > I think this is a little confusing, esepecially that the comment
> > > > of InterfaceStability also mentions the compatibility for patch,
> minor
> > > and
> > > > major release.
> > > >
> > > > For me, I think only InterfaceStability.Unstable is useful for public
> > > API.
> > > > It means the API is still experimental and will not respect the
> > > > compatibility rule.
> > > >
> > > > So here I suggest we just remove the InterfaceStability annoation for
> > the
> > > > classes which are marked as InterfaceAudience.Public, and change the
> > > > comment of InterfaceStability and also the refguide to be more
> > specific.
> > > >
> > > > Suggestions are welcomed.
> > > >
> > > > Thanks.
> > >
> >
>

Re: Multiple match's Filter is NOT WORKING

[Josh Elser]

Yoom,

Please leave conversation on the mailing list.

I am suggesting that you create a standalone application which writes data
in your format and then tries to read it using your filter logic that
doesn't work. It should be something that we can run. This would let us
actually see what isn't working.


On Mar 20, 2017 20:45, "Yoom Nguyen"  wrote:


Josh,

Thank you for replying.  I am not quite sure how to do what you are
suggesting.  I will have figure it out.
Sorry, I am not trying to threatening, we like HBASE that is why we choose
it as a technology for our project.
I am run into a road block and not while sure how to proceed from here
without getting data back correctly from
HBASE.  We could not move forward due to the problem we are having.

Can you help?  or suggest someone might interest and can help.  I will send
you give a dinner gift certificate to where you want to go for two if you
could look into my problem and provide some suggestion.

Thanks,
Yoom

- Original Message -
From: "Josh Elser" 
To: dev@hbase.apache.org
Sent: Monday, March 20, 2017 6:29:41 PM
Subject: Re: Multiple match's Filter is NOT WORKING

If you could encapsulate what you're trying to do into a
unit-test/standalone class, it would likely be much more approachable
for anyone to reproduce and help debug your issues.

You've provided a lot of information, but very little of it is helpful
in actually figuring out why what you've done doesn't work. Most of the
time, the devil is in the details which your code snippets wouldn't
capture in the first place.

Please do remember that we're all volunteers. We want to try to help,
but you'll get a much better response with the carrot (effort from your
side to show what doesn't work) than the stick (threatening to "give up
using HBase").

Yoom Nguyen wrote:
> Would anyone know if this is the right forum to ask this type of
question? If not, would you suggest where I should try to ask this type of
question before I am giving up using HBASE all together.
> I am stuck for a while now and not able to get any advice from anyone.
>
> Thanks in advance,
> Yoom
>
> - Original Message -
>
> From: "Yoom Nguyen"
> To: dev@hbase.apache.org
> Sent: Sunday, March 19, 2017 5:46:17 PM
> Subject: Multiple match's Filter is NOT WORKING
>
>
> I am having problems getting correct match's results from searching
through multiple HBASE's tables.
> Is there a bug in HBASE's filter? Wondering if anyone know HBASE \ Java
well and willing to help out or for a fee.
> Is this a bug with HBASE?
>
> HBASE Release 0.98.8 - 11/18/2014
>
>
> Would someone help me out with the problem or confirmation whether HBASE
is the right tool or not.
>
> Here are the details of the problem:
> First I am reading some data from one table and storing in a vector or
arrayList: Is there a better way or different approach to achieve the
results than what I am heading? I am stuck trying to get the correct
results with the following approach.
>
> //First, I am reading some data from one table and storing in a vector or
arrayList:
>
> for (Result r : rs) {
> for (KeyValue kv : r.raw()) {
> if (new String(kv.getFamily()).equals("name")) {
> temp = new String(kv.getValue());
> x.addElement(temp);
> }
> }
> }
>
>
> //Then, I want to search a different table based on the values of this
vector.
> //I used filters to do this: (I tried BinaryPrefixComparator and
BinaryComparator as well)
>
>
> FilterList filterList = new FilterList(FilterList.Operator.MUST_PASS_ONE);
>
> for (int c = 0; c<  x.size(); c++) {
> System.out.println(x.get(c).toString());
> filterList.addFilter(new SingleColumnValueFilter(Bytes.toBytes("name"),
null,
> CompareOp.EQUAL, new SubstringComparator( x.get(c).toString() )));
> }
>
> //I should get 3 results back, however I only get one result back, the
first entry in the database.
> What doesn't make sense is that when I hardcode the value that I am
looking for into my code, I will get all 3 results back.
>
> I thought there might be some issue with converting the bytes to String
and then back to bytes, but that would not explain how it was able to bring
back the first result. For some reason, it is stopping at the first match
and doesn't continue to find the other 2 rows that contain matching data.
If I hardcode it i get the results:
>
>
> x.addElement("abc123");
> filterList.addFilter(new SingleColumnValueFilter(Bytes.toBytes("mpnum"),
null, CompareOp.EQUAL, new SubstringComparator( x.get(0).toString() )));
>
>
> edit: Here is the contents of the tables:
>
> TABLE1: ROW COLUMN+CELL
> 0 column=gpnum:, timestamp=1481300288449, value=def123
> 0 column=mpnum:, timestamp=1481300273355, value=abc123
> 0 column=price:, timestamp=1481300255337, value=85.0
> 1 column=gpnum:, timestamp=148130159, value=def2244
> 1 column=mpnum:, timestamp=1481301582336, value=011511607
> 1 column=price:, timestamp=1481301673886, value=0.76
>
> TABLE2
>
> ROW COLUMN+CELL
> 0 

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/527/artifact/website.patch.zip
 | funzip > 9c8f02e4ef3037e8eaf649360ce83a898c3b20e1.patch
  git fetch
  git checkout -b asf-site-9c8f02e4ef3037e8eaf649360ce83a898c3b20e1 
origin/asf-site
  git am --whitespace=fix 9c8f02e4ef3037e8eaf649360ce83a898c3b20e1.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-9c8f02e4ef3037e8eaf649360ce83a898c3b20e1 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-9c8f02e4ef3037e8eaf649360ce83a898c3b20e1:asf-site
  git checkout asf-site
  git branch -D asf-site-9c8f02e4ef3037e8eaf649360ce83a898c3b20e1

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/527/console

Re: ANNOUNCE: Good news!!!! Two new PMC and a new Committer!

[Nick Dimiduk]

Quite an on-boarding. Congratulations all!

On Thu, Mar 16, 2017 at 10:37 PM, Stack  wrote:

> Josh Elser and Jing Chen (Jerry) have both been added to the HBase PMC.
> These lads have been stellar helping the project along; Jerry for a good
> few years now and Josh, though less time served, has made up for the lack
> with style. It makes sense that they be made PMCers!
>
> Let me take this opportunity while I have your attention to also welcome
> Eshcar Hillel as a Committer on Apache HBase. We are very glad to have her
> on-board. She's a brainbox who has been working on the inmemory compaction
> project among other things and is without fear when it comes to taking a
> deep dive into crud!
>
> Welcome aboard Josh, Jing Chen He, and Eshcar!
>
> St.Ack
>

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/524/artifact/website.patch.zip
 | funzip > e39e0e634a2252a352ad799bc2957c72e8d2d2e9.patch
  git fetch
  git checkout -b asf-site-e39e0e634a2252a352ad799bc2957c72e8d2d2e9 
origin/asf-site
  git am --whitespace=fix e39e0e634a2252a352ad799bc2957c72e8d2d2e9.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-e39e0e634a2252a352ad799bc2957c72e8d2d2e9 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-e39e0e634a2252a352ad799bc2957c72e8d2d2e9:asf-site
  git checkout asf-site
  git branch -D asf-site-e39e0e634a2252a352ad799bc2957c72e8d2d2e9

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/524/console

Failure: HBase Generate Website

[Apache Jenkins Server]

Build status: Failure

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/525/artifact/website.patch.zip
 | funzip > ${GIT_SHA}.patch
  git fetch
  git checkout -b asf-site-${GIT_SHA} origin/asf-site
  git am --whitespace=fix $GIT_SHA.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local asf-site-${GIT_SHA} branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-${GIT_SHA}:asf-site
  git checkout asf-site
  git branch -D asf-site-${GIT_SHA}

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/525/console

Aborted: hbase.apache.org HTML Checker

[Apache Jenkins Server]

Aborted

If successful, the HTML and link-checking report for http://hbase.apache.org is 
available at 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/87/artifact/link_report/index.html.

If failed, see 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/87/console.

[jira] [Created] (HBASE-17811) TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in "branch-1"

[Anup Halarnkar (JIRA)]

Anup Halarnkar created HBASE-17811:
--

 Summary: 
TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in 
"branch-1"
 Key: HBASE-17811
 URL: https://issues.apache.org/jira/browse/HBASE-17811
 Project: HBase
  Issue Type: Bug
  Components: Thrift
Affects Versions: 2.0.0
 Environment: OS: Ubuntu 14.04
Arch:x86_64
Reporter: Anup Halarnkar
 Fix For: 2.0.0


Module Thrift fails with this output:
Results :

Failed tests:
  TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength
Expected: (an instance of org.apache.thrift.transport.TTransportException and 
exception with message a string containing "HTTP Response code: 413")
 but: exception with message a string containing "HTTP Response code: 413" 
message was "java.net.ConnectException: Connection refused (Connection refused)"
Stacktrace was: org.apache.thrift.transport.TTransportException: 
java.net.ConnectException: Connection refused (Connection refused)
at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:356)
at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:73)
at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62)
at 
org.apache.hadoop.hbase.thrift.generated.Hbase$Client.send_getTableNames(Hbase.java:901)
at 
org.apache.hadoop.hbase.thrift.generated.Hbase$Client.getTableNames(Hbase.java:894)
at 
org.apache.hadoop.hbase.thrift.TestThriftServer.checkTableList(TestThriftServer.java:248)
at 
org.apache.hadoop.hbase.thrift.TestThriftHttpServer.talkToThriftServer(TestThriftHttpServer.java:187)
at 
org.apache.hadoop.hbase.thrift.TestThriftHttpServer.runThriftServer(TestThriftHttpServer.java:147)
at 
org.apache.hadoop.hbase.thrift.TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength(TestThriftHttpServer.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at 
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at sun.net.www.http.HttpClient.New(HttpClient.java:326)
at 
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1202)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1138)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1032)
at 
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:966)
at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:344)
... 20 more


Tests run: 88, Failures: 1, Errors: 0, Skipped: 0




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17810) TestFuzzyRowFilter and IntegrationTest* tests on "branch-1" are broken

[Anup Halarnkar (JIRA)]

Anup Halarnkar created HBASE-17810:
--

 Summary: TestFuzzyRowFilter and IntegrationTest* tests on 
"branch-1" are broken
 Key: HBASE-17810
 URL: https://issues.apache.org/jira/browse/HBASE-17810
 Project: HBase
  Issue Type: Bug
  Components: integration tests
Affects Versions: 2.0.0
 Environment: OS: Ubuntu 14.04
Arch: ppc64le

Reporter: Anup Halarnkar
 Fix For: 2.0.0


I saw that some fixes HBASE-17746 were in branch-1. So, I used this branch to 
see if I am getting any failures.
This is the result:
Results :

Failed tests:
  TestFuzzyRowFilter.testSatisfiesForward:80 expected: but was:
  TestFuzzyRowFilter.testSatisfiesReverse:120 expected: but 
was:
Tests in error:
  
TestSeekToBlockWithEncoders.testSeekToBlockWithDecreasingCommonPrefix:140->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekToBlockWithDiffFamilyAndQualifer:249->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekToBlockWithDiffQualifer:160->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekToBlockWithDiffQualiferOnSameRow:183->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekToBlockWithDiffQualiferOnSameRow1:206->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekToBlockWithDiffQualiferOnSameRowButDescendingInSize:229->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekToBlockWithNonMatchingSeekKey:65->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekingToBlockToANotAvailableKey:117->seekToTheKey:270
 » NoClassDefFound
  
TestSeekToBlockWithEncoders.testSeekingToBlockWithBiggerNonLength1:91->seekToTheKey:270
 » NoClassDefFound
  TestHFileEncryption.testHFileEncryption:232 » NoClassDefFound Could not 
initia...
  
TestSeekTo.testSeekBeforeWithReSeekTo:199->testSeekBeforeWithReSeekToInternals:216
 » NoClassDefFound
  TestSeekTo.testSeekBefore:145->testSeekBeforeInternals:161 » NoClassDefFound 
C...
  TestSeekTo.testSeekTo:292->testSeekToInternals:308 » NoClassDefFound Could 
not...

Tests run: 1106, Failures: 2, Errors: 13, Skipped: 22

Results :

Failed tests:
  IntegrationTestRegionReplicaReplication.testIngest:112->runIngestTest:214 
Load failed with error code 1
  IntegrationTestBulkLoad.testBulkLoad:213->runLoad:223->runLinkedListMRJob:296 
expected: but was:
  IntegrationTestImportTsv.testGenerateAndLoad:203 expected:<0> but was:<1>
  IntegrationTestLoadAndVerify.testLoadAndVerify:544->doLoad:353 null
  
IntegrationTestWithCellVisibilityLoadAndVerify>IntegrationTestLoadAndVerify.testLoadAndVerify:544->doLoad:244->IntegrationTestLoadAndVerify.doLoad:353
 null
Tests in error:
  
IntegrationTestIngestWithACL>IntegrationTestBase.setUp:148->setUpCluster:64->IntegrationTestIngest.setUpCluster:84
 » IO
  IntegrationTestMTTR.testKillRsHoldingMeta:278->run:319 » Execution 
java.io.IOE...
  IntegrationTestMTTR.testRestartRsHoldingTable:273->run:319 » Execution 
java.io...
  IntegrationTestBigLinkedList.testContinuousIngest:1798 » Runtime Generator 
fai...
  IntegrationTestBigLinkedListWithVisibility.testContinuousIngest:637 » Runtime 
...
  
IntegrationTestReplication>IntegrationTestBigLinkedList.testContinuousIngest:1798
 » Runtime

Tests run: 32, Failures: 5, Errors: 6, Skipped: 2

Any idea what could be the reason for above failures?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17809) cleanup unused class

[Chia-Ping Tsai (JIRA)]

Chia-Ping Tsai created HBASE-17809:
--

 Summary: cleanup unused class
 Key: HBASE-17809
 URL: https://issues.apache.org/jira/browse/HBASE-17809
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
 Fix For: 2.0.0


inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of 
commits. We shall remove them.

||class||last meeting||why||line count|
|LruHashMap|HBASE-1822|get rid of|1100|
|ScannerTimeoutException|HBASE-16266|get rid of|45|
|SortedCopyOnWriteSet|HBASE-12748|get rid of|178|
|TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107|
|DelegatingRetryingCallable|HBASE-9049|create but never used|65|
|LockTimeoutException|HBASE-16786|get rid of|44|
|OperationConflictException|HBASE-9899|get rid of|50|
|InvalidQuotaSettingsException|HBASE-11598|create but never used|33|
|ShareableMemory|HBASE-15735|get rid of|40|
|BoundedArrayQueue|HBASE-14860|get rid of|82|
|TestBoundedArrayQueue|HBASE-14860|get rid of|61|
|ChecksumFactory|HBASE-11927|get rid of|100|
|TokenDepthComparator|HBASE-4676|create but never used|65|
|RegionMergeTransaction|HBASE-17470|get rid of|249|
|MetaUtils|HBASE-1822|get rid of|156|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17812) Remove RpcConnection from pool in AbstractRpcClient.cancelConnections

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-17812:
-

 Summary: Remove RpcConnection from pool in 
AbstractRpcClient.cancelConnections
 Key: HBASE-17812
 URL: https://issues.apache.org/jira/browse/HBASE-17812
 Project: HBase
  Issue Type: Bug
  Components: Client, rpc
Affects Versions: 2.0.0
Reporter: Duo Zhang
Assignee: Duo Zhang
 Fix For: 2.0.0


Found it when backporting the new rpc implementation to branch-1 in 
HBASE-16584. It will cause TestHCM fail on branch-1 as on branch-1 the default 
rpc implementation is BlockingRpcClient which is not always reconnectable after 
shutdown. On master TestHCM will not fail as NettyRpcConnection is always 
reconnectable. But we still need to fix it as it is a bug. Only a trivial one 
line patch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17808) FastPath for RWQueueRpcExecutor

[Allan Yang (JIRA)]

Allan Yang created HBASE-17808:
--

 Summary: FastPath for RWQueueRpcExecutor
 Key: HBASE-17808
 URL: https://issues.apache.org/jira/browse/HBASE-17808
 Project: HBase
  Issue Type: Improvement
  Components: rpc
Affects Versions: 2.0.0
Reporter: Allan Yang
Assignee: Allan Yang


FastPath for the FIFO rpcscheduler was introduced in HBASE-16023. But it is not 
implemented for RW queues. In this issue, I use 
FastPathBalancedQueueRpcExecutor in RW queues. So anyone who want to isolate 
their read/write requests can also benefit from the fastpath.
I haven't test the performance yet. But since I haven't change any of the core 
implemention of FastPathBalancedQueueRpcExecutor, it should have the same 
performance in HBASE-16023.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-12579) Move obtainAuthTokenForJob() methods out of User

[Gary Helmling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-12579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Helmling resolved HBASE-12579.
---
Resolution: Duplicate

The methods were deprecated and the existing usage was removed as part of 
HBASE-12493.  I guess I left this open for the final removal of the deprecated 
methods from the next major release.  The removal was done as part of 
HBASE-14208.

> Move obtainAuthTokenForJob() methods out of User
> 
>
> Key: HBASE-12579
> URL: https://issues.apache.org/jira/browse/HBASE-12579
> Project: HBase
>  Issue Type: Improvement
>  Components: security
>Reporter: Gary Helmling
>
> The {{User}} class currently contains some utility methods to obtain HBase 
> authentication tokens for the given user.  However, these methods initiate an 
> RPC to the {{TokenProvider}} coprocessor endpoint, an action which should not 
> be part of the User class' responsibilities.
> This leads to a couple of problems:
> # The way the methods are currently structured, it is impossible to integrate 
> them with normal connection management for the cluster (the TokenUtil class 
> constructs its own HTable instance internally).
> # The User class is logically part of the hbase-common module, but uses the 
> TokenUtil class (part of hbase-server, though it should probably be moved to 
> hbase-client) through reflection, leading to a hidden dependency.
> The {{obtainAuthTokenForJob()}} methods should be deprecated and the process 
> of obtaining authentication tokens should be moved to use the normal 
> connection lifecycle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

[Sean Busbey]

On Mon, Mar 20, 2017 at 11:09 AM, Ted Yu  wrote:
> Is Yetus 0.4.0 release stable ?
>

yes.


> If we use Yetus annotations, is there only one jar pulled in as dependency ?
>

IIRC, we'll get one jar as a dependency. There shouldn't be any
transitive dependencies involved.

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

[Ted Yu]

Is Yetus 0.4.0 release stable ?

If we use Yetus annotations, is there only one jar pulled in as dependency ?

Cheers

On Mon, Mar 20, 2017 at 7:26 AM, Sean Busbey  wrote:

> Hi folks!
>
> I'd like us to start moving towards using the audience annotations
> from the Apache Yetus project[1] so we can remove the same kind of
> implementation code from our codebase.
>
> For background, a while ago Apache Hadoop made some Java annotations
> to denote what APIs were appropriate for downstream use (rather than
> those intended for use by the project itself). This was to deal with
> the disconnect between the access modifiers available in Java and the
> project's structure wrt downstream.
>
> When HBase grew out of the Hadoop project, we adopted the same
> annotations[2]. Eventually, we moved to having our own copy of those
> classes and the attendant javadocs plugin for customizing our
> downstream facing docs[3].
>
> Apache Yetus formed about about a year and a half ago to serve as a
> common point of support for tools that help projects handle community
> matters, you may recognize it from the precommit test framework we
> rely on to vet incoming patches. Yetus also provides a single
> implementation of the annotations and javadoc work that currently
> resides in both the Hadoop and HBase projects.
>
> Since 2.0 is a major version, we could just switch wholesale from our
> own implementations to the most recent Apache Yetus release.
> Alternatively, we could have 2.0 serve as a transitionary release line
> that annotates things with both our own and the Yetus versions of the
> Inteface Audience markings.
>
> Personally, I'd prefer just swapping things out all at once. This
> would have the happy side-effect of removing a cyclic dependency in
> our build (where one needs to have built our annotation processing
> javadoc plugin).
>
> What do folks think?
>
> -Sean
>
> [1]: http://yetus.apache.org/documentation/0.4.0/interface-classification/
> [2]: http://hbase.apache.org/book.html#hbase.client.api.surface
> [3]: https://issues.apache.org/jira/browse/HBASE-12059
>

[DISCUSS] moving to Apache Yetus Audience Annotations

[Sean Busbey]

Hi folks!

I'd like us to start moving towards using the audience annotations
from the Apache Yetus project[1] so we can remove the same kind of
implementation code from our codebase.

For background, a while ago Apache Hadoop made some Java annotations
to denote what APIs were appropriate for downstream use (rather than
those intended for use by the project itself). This was to deal with
the disconnect between the access modifiers available in Java and the
project's structure wrt downstream.

When HBase grew out of the Hadoop project, we adopted the same
annotations[2]. Eventually, we moved to having our own copy of those
classes and the attendant javadocs plugin for customizing our
downstream facing docs[3].

Apache Yetus formed about about a year and a half ago to serve as a
common point of support for tools that help projects handle community
matters, you may recognize it from the precommit test framework we
rely on to vet incoming patches. Yetus also provides a single
implementation of the annotations and javadoc work that currently
resides in both the Hadoop and HBase projects.

Since 2.0 is a major version, we could just switch wholesale from our
own implementations to the most recent Apache Yetus release.
Alternatively, we could have 2.0 serve as a transitionary release line
that annotates things with both our own and the Yetus versions of the
Inteface Audience markings.

Personally, I'd prefer just swapping things out all at once. This
would have the happy side-effect of removing a cyclic dependency in
our build (where one needs to have built our annotation processing
javadoc plugin).

What do folks think?

-Sean

[1]: http://yetus.apache.org/documentation/0.4.0/interface-classification/
[2]: http://hbase.apache.org/book.html#hbase.client.api.surface
[3]: https://issues.apache.org/jira/browse/HBASE-12059

Re: About the InterfaceStability annotation for public API

[Sean Busbey]

I really dislike having InterfaceStability markings on IA.Public
interfaces, because to me it reads like us essentially saying we
didn't invest enough time in deciding what something should look like
before declaring it safe for downstream folks. If someone is
comfortable with the risk of an API that can change in minor or
maintenance releases, what's gained by calling it IA.Public +
IS.Evolving or Unstable rather than just labeling it IA.Private or
IA.LimitedPrivate?

So I'd be +1 on updating our docs to state that InterfaceStability is
just for IA.LimitedPrivate or even discontinuing our use of it
entirely.

On Sun, Mar 19, 2017 at 11:28 PM, Duo Zhang  wrote:
> In the compatibility section of our refguide, the compatibility for patch
> version, minor version and major version is not related
> to InterfaceStability annotation. The only place we mention it is for
> Server-Side Limited API compatibility.
>
> And  in the Developer Guidelines section, we say this
> @InterfaceStability.Evolving
>
> Public packages marked as evolving may be changed, but it is discouraged.
> I think this is a little confusing, esepecially that the comment
> of InterfaceStability also mentions the compatibility for patch, minor and
> major release.
>
> For me, I think only InterfaceStability.Unstable is useful for public API.
> It means the API is still experimental and will not respect the
> compatibility rule.
>
> So here I suggest we just remove the InterfaceStability annoation for the
> classes which are marked as InterfaceAudience.Public, and change the
> comment of InterfaceStability and also the refguide to be more specific.
>
> Suggestions are welcomed.
>
> Thanks.

Re: [VOTE] First release candidate for HBase 1.2.5 is available

[Sean Busbey]

Hi Josh!

Are you comfortable with me considering your vote binding now that
you're a PMC member?

On Sat, Mar 11, 2017 at 5:24 PM, Josh Elser  wrote:
> +1 (non-binding)
>
> * xsums/sigs OK
> * Compat report looks OK for a patch release
> * Spot-checked source release and ran apache-rat:check
> * Can build from source (and run a subset of tests)
> * KEYS has the signing key
> * Commit is in source repository
>
>
> Sean Busbey wrote:
>>
>> The first release candidate for HBase 1.2.5 is available for download at:
>>
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
>>
>> Maven artifacts are also available in a staging repository at:
>>
>> https://repository.apache.org/content/repositories/orgapachehbase-1164/
>>
>> Artifacts are signed with my key (0D80DB7C) published in our KEYS
>> file at http://www.apache.org/dist/hbase/KEYS
>>
>> The RC corresponds to the signed tag 1.2.5RC0, which currently points
>> to commit ref
>>
>> d7b05f79dee10e0ada614765bb354b93d615a157
>>
>> The detailed source and binary compatibility report vs 1.2.4 has been
>> published for your review, at:
>>
>>
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/1.2.4_1.2.5RC0_compat_report.html
>>
>> Note that this report calls out the issue discussed in HBASE-17725.
>>
>> HBase 1.2.5 is the fifth maintenance release in the HBase 1.2 line,
>> continuing on
>> the theme of bringing a stable, reliable database to the Hadoop and NoSQL
>> communities. This release includes over 50 bug fixes since 1.2.4.
>> Critical fixes include:
>>
>> * HBASE-17069 RegionServer writes invalid META entries for split
>> daughters in some circumstances
>> * HBASE-17044 Fix merge failed before creating merged region leaves
>> meta inconsistent
>> * HBASE-17206 FSHLog may roll a new writer successfully with unflushed
>> entries
>> * HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
>> spread of regions for small tables.
>>
>>
>> The full list of fixes included in this release is available at:
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338339=12310753
>>
>> and in the CHANGES.txt file included in the distribution.
>>
>> Please try out this candidate and vote +1/-1 on whether we should
>> release these artifacts as HBase 1.2.5.
>>
>> The VOTE will remain open for atleast 72 hours. Given sufficient votes
>> I would like to close it on March 17th, 2017.
>>
>> thanks!

Re: [VOTE] First release candidate for HBase 1.2.5 is available

[Sean Busbey]

Hi Jerry!

Are you comfortable with me considering your vote as binding now that
you're a PMC member?

On Wed, Mar 15, 2017 at 7:12 PM, Jerry He  wrote:
> +1
>
> (non-binding)
>
>
> - Downloaded the src tarball.
>   - Checked the md5 and signature.  Looks good.
>   - Built from source.  openjdk version "1.8.0_121"
>   - Ran unit test suite twice.  All passed.
>   - mvn apache-rat:check   Passed
>
> - Download the bin tarball.
>  -  Checked the md5 and signature.  Looks good.
>  -  Extract it.   Layout looks good.
>  -  Started a local instance.  Run the 'hbase shell' with some basic table
> commands, split, flush, etc.  Looks good.
>  -  Nothing unusual in the logs.
>  -  Check master and region server UI.  Clicked on the tabs, looked at the
> tasks running, Debug dump, Configuration dump, zk dump. Looks good.
>
> - Built Phoenix 4.9-HBase-1.2 with hbase version 1.2.5 pointing to the RC
> maven repo URL.
>   Ran unit tests.  All passed.
>
> -  Bulit YCSB 0.12.0 from git source with HBase binding version 1.2.5
> pointing to RC.
> -  Run YCSB workloads again the local RC instance.  Worked fine.
>
> Jerry
>
>
> On Mon, Mar 13, 2017 at 9:50 PM, Andrew Purtell  wrote:
>
>> +1
>>
>> Checked sums and signatures: ok
>> Built from source: ok (7u80)
>> RAT check passed: ok (7u80)
>> Unit tests pass: ok (8u102)
>> Loaded 1M rows with LTT: ok (8u102), all keys verified, latencies in the
>> ballpark, nothing unusual in the logs
>>
>>
>> On Fri, Mar 10, 2017 at 2:31 PM, Sean Busbey  wrote:
>>
>> > The first release candidate for HBase 1.2.5 is available for download at:
>> >
>> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
>> >
>> > Maven artifacts are also available in a staging repository at:
>> >
>> > https://repository.apache.org/content/repositories/orgapachehbase-1164/
>> >
>> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
>> > file at http://www.apache.org/dist/hbase/KEYS
>> >
>> > The RC corresponds to the signed tag 1.2.5RC0, which currently points
>> > to commit ref
>> >
>> > d7b05f79dee10e0ada614765bb354b93d615a157
>> >
>> > The detailed source and binary compatibility report vs 1.2.4 has been
>> > published for your review, at:
>> >
>> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
>> > 1.2.4_1.2.5RC0_compat_report.html
>> >
>> > Note that this report calls out the issue discussed in HBASE-17725.
>> >
>> > HBase 1.2.5 is the fifth maintenance release in the HBase 1.2 line,
>> > continuing on
>> > the theme of bringing a stable, reliable database to the Hadoop and NoSQL
>> > communities. This release includes over 50 bug fixes since 1.2.4.
>> > Critical fixes include:
>> >
>> > * HBASE-17069 RegionServer writes invalid META entries for split
>> > daughters in some circumstances
>> > * HBASE-17044 Fix merge failed before creating merged region leaves
>> > meta inconsistent
>> > * HBASE-17206 FSHLog may roll a new writer successfully with unflushed
>> > entries
>> > * HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
>> > spread of regions for small tables.
>> >
>> >
>> > The full list of fixes included in this release is available at:
>> >
>> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > version=12338339=12310753
>> >
>> > and in the CHANGES.txt file included in the distribution.
>> >
>> > Please try out this candidate and vote +1/-1 on whether we should
>> > release these artifacts as HBase 1.2.5.
>> >
>> > The VOTE will remain open for atleast 72 hours. Given sufficient votes
>> > I would like to close it on March 17th, 2017.
>> >
>> > thanks!
>> >
>>
>>
>>
>> --
>> Best regards,
>>
>>- Andy
>>
>> If you are given a choice, you believe you have acted freely. - Raymond
>> Teller (via Peter Watts)
>>



-- 
Sean

Re: [VOTE] First release candidate for HBase 1.2.5 is available

[Sean Busbey]

I do. :)

On Mon, Mar 20, 2017 at 10:22 AM, Jerry He  wrote:
> Sure, what the RM feels it is ok and reasonable.
>
> Jerry
>
> On Mon, Mar 20, 2017 at 8:01 AM, Sean Busbey  wrote:
>
>> Hi Jerry!
>>
>> Are you comfortable with me considering your vote as binding now that
>> you're a PMC member?
>>
>> On Wed, Mar 15, 2017 at 7:12 PM, Jerry He  wrote:
>> > +1
>> >
>> > (non-binding)
>> >
>> >
>> > - Downloaded the src tarball.
>> >   - Checked the md5 and signature.  Looks good.
>> >   - Built from source.  openjdk version "1.8.0_121"
>> >   - Ran unit test suite twice.  All passed.
>> >   - mvn apache-rat:check   Passed
>> >
>> > - Download the bin tarball.
>> >  -  Checked the md5 and signature.  Looks good.
>> >  -  Extract it.   Layout looks good.
>> >  -  Started a local instance.  Run the 'hbase shell' with some basic
>> table
>> > commands, split, flush, etc.  Looks good.
>> >  -  Nothing unusual in the logs.
>> >  -  Check master and region server UI.  Clicked on the tabs, looked at
>> the
>> > tasks running, Debug dump, Configuration dump, zk dump. Looks good.
>> >
>> > - Built Phoenix 4.9-HBase-1.2 with hbase version 1.2.5 pointing to the RC
>> > maven repo URL.
>> >   Ran unit tests.  All passed.
>> >
>> > -  Bulit YCSB 0.12.0 from git source with HBase binding version 1.2.5
>> > pointing to RC.
>> > -  Run YCSB workloads again the local RC instance.  Worked fine.
>> >
>> > Jerry
>> >
>> >
>> > On Mon, Mar 13, 2017 at 9:50 PM, Andrew Purtell 
>> wrote:
>> >
>> >> +1
>> >>
>> >> Checked sums and signatures: ok
>> >> Built from source: ok (7u80)
>> >> RAT check passed: ok (7u80)
>> >> Unit tests pass: ok (8u102)
>> >> Loaded 1M rows with LTT: ok (8u102), all keys verified, latencies in the
>> >> ballpark, nothing unusual in the logs
>> >>
>> >>
>> >> On Fri, Mar 10, 2017 at 2:31 PM, Sean Busbey  wrote:
>> >>
>> >> > The first release candidate for HBase 1.2.5 is available for download
>> at:
>> >> >
>> >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
>> >> >
>> >> > Maven artifacts are also available in a staging repository at:
>> >> >
>> >> > https://repository.apache.org/content/repositories/
>> orgapachehbase-1164/
>> >> >
>> >> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
>> >> > file at http://www.apache.org/dist/hbase/KEYS
>> >> >
>> >> > The RC corresponds to the signed tag 1.2.5RC0, which currently points
>> >> > to commit ref
>> >> >
>> >> > d7b05f79dee10e0ada614765bb354b93d615a157
>> >> >
>> >> > The detailed source and binary compatibility report vs 1.2.4 has been
>> >> > published for your review, at:
>> >> >
>> >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
>> >> > 1.2.4_1.2.5RC0_compat_report.html
>> >> >
>> >> > Note that this report calls out the issue discussed in HBASE-17725.
>> >> >
>> >> > HBase 1.2.5 is the fifth maintenance release in the HBase 1.2 line,
>> >> > continuing on
>> >> > the theme of bringing a stable, reliable database to the Hadoop and
>> NoSQL
>> >> > communities. This release includes over 50 bug fixes since 1.2.4.
>> >> > Critical fixes include:
>> >> >
>> >> > * HBASE-17069 RegionServer writes invalid META entries for split
>> >> > daughters in some circumstances
>> >> > * HBASE-17044 Fix merge failed before creating merged region leaves
>> >> > meta inconsistent
>> >> > * HBASE-17206 FSHLog may roll a new writer successfully with unflushed
>> >> > entries
>> >> > * HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
>> >> > spread of regions for small tables.
>> >> >
>> >> >
>> >> > The full list of fixes included in this release is available at:
>> >> >
>> >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> >> > version=12338339=12310753
>> >> >
>> >> > and in the CHANGES.txt file included in the distribution.
>> >> >
>> >> > Please try out this candidate and vote +1/-1 on whether we should
>> >> > release these artifacts as HBase 1.2.5.
>> >> >
>> >> > The VOTE will remain open for atleast 72 hours. Given sufficient votes
>> >> > I would like to close it on March 17th, 2017.
>> >> >
>> >> > thanks!
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >>- Andy
>> >>
>> >> If you are given a choice, you believe you have acted freely. - Raymond
>> >> Teller (via Peter Watts)
>> >>
>>
>>
>>
>> --
>> Sean
>>



-- 
Sean

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/521/artifact/website.patch.zip
 | funzip > 5b4bb8217dd4327a89fa29c93ac37bc887d96c2c.patch
  git fetch
  git checkout -b asf-site-5b4bb8217dd4327a89fa29c93ac37bc887d96c2c 
origin/asf-site
  git am --whitespace=fix 5b4bb8217dd4327a89fa29c93ac37bc887d96c2c.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-5b4bb8217dd4327a89fa29c93ac37bc887d96c2c branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-5b4bb8217dd4327a89fa29c93ac37bc887d96c2c:asf-site
  git checkout asf-site
  git branch -D asf-site-5b4bb8217dd4327a89fa29c93ac37bc887d96c2c

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/521/console

Re: [VOTE] First release candidate for HBase 1.2.5 is available

[Jerry He]

Sure, what the RM feels it is ok and reasonable.

Jerry

On Mon, Mar 20, 2017 at 8:01 AM, Sean Busbey  wrote:

> Hi Jerry!
>
> Are you comfortable with me considering your vote as binding now that
> you're a PMC member?
>
> On Wed, Mar 15, 2017 at 7:12 PM, Jerry He  wrote:
> > +1
> >
> > (non-binding)
> >
> >
> > - Downloaded the src tarball.
> >   - Checked the md5 and signature.  Looks good.
> >   - Built from source.  openjdk version "1.8.0_121"
> >   - Ran unit test suite twice.  All passed.
> >   - mvn apache-rat:check   Passed
> >
> > - Download the bin tarball.
> >  -  Checked the md5 and signature.  Looks good.
> >  -  Extract it.   Layout looks good.
> >  -  Started a local instance.  Run the 'hbase shell' with some basic
> table
> > commands, split, flush, etc.  Looks good.
> >  -  Nothing unusual in the logs.
> >  -  Check master and region server UI.  Clicked on the tabs, looked at
> the
> > tasks running, Debug dump, Configuration dump, zk dump. Looks good.
> >
> > - Built Phoenix 4.9-HBase-1.2 with hbase version 1.2.5 pointing to the RC
> > maven repo URL.
> >   Ran unit tests.  All passed.
> >
> > -  Bulit YCSB 0.12.0 from git source with HBase binding version 1.2.5
> > pointing to RC.
> > -  Run YCSB workloads again the local RC instance.  Worked fine.
> >
> > Jerry
> >
> >
> > On Mon, Mar 13, 2017 at 9:50 PM, Andrew Purtell 
> wrote:
> >
> >> +1
> >>
> >> Checked sums and signatures: ok
> >> Built from source: ok (7u80)
> >> RAT check passed: ok (7u80)
> >> Unit tests pass: ok (8u102)
> >> Loaded 1M rows with LTT: ok (8u102), all keys verified, latencies in the
> >> ballpark, nothing unusual in the logs
> >>
> >>
> >> On Fri, Mar 10, 2017 at 2:31 PM, Sean Busbey  wrote:
> >>
> >> > The first release candidate for HBase 1.2.5 is available for download
> at:
> >> >
> >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
> >> >
> >> > Maven artifacts are also available in a staging repository at:
> >> >
> >> > https://repository.apache.org/content/repositories/
> orgapachehbase-1164/
> >> >
> >> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
> >> > file at http://www.apache.org/dist/hbase/KEYS
> >> >
> >> > The RC corresponds to the signed tag 1.2.5RC0, which currently points
> >> > to commit ref
> >> >
> >> > d7b05f79dee10e0ada614765bb354b93d615a157
> >> >
> >> > The detailed source and binary compatibility report vs 1.2.4 has been
> >> > published for your review, at:
> >> >
> >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
> >> > 1.2.4_1.2.5RC0_compat_report.html
> >> >
> >> > Note that this report calls out the issue discussed in HBASE-17725.
> >> >
> >> > HBase 1.2.5 is the fifth maintenance release in the HBase 1.2 line,
> >> > continuing on
> >> > the theme of bringing a stable, reliable database to the Hadoop and
> NoSQL
> >> > communities. This release includes over 50 bug fixes since 1.2.4.
> >> > Critical fixes include:
> >> >
> >> > * HBASE-17069 RegionServer writes invalid META entries for split
> >> > daughters in some circumstances
> >> > * HBASE-17044 Fix merge failed before creating merged region leaves
> >> > meta inconsistent
> >> > * HBASE-17206 FSHLog may roll a new writer successfully with unflushed
> >> > entries
> >> > * HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
> >> > spread of regions for small tables.
> >> >
> >> >
> >> > The full list of fixes included in this release is available at:
> >> >
> >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >> > version=12338339=12310753
> >> >
> >> > and in the CHANGES.txt file included in the distribution.
> >> >
> >> > Please try out this candidate and vote +1/-1 on whether we should
> >> > release these artifacts as HBase 1.2.5.
> >> >
> >> > The VOTE will remain open for atleast 72 hours. Given sufficient votes
> >> > I would like to close it on March 17th, 2017.
> >> >
> >> > thanks!
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >>- Andy
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymond
> >> Teller (via Peter Watts)
> >>
>
>
>
> --
> Sean
>

Re: [ANNOUNCE] New HBase committer Chia-Ping Tsai

[Esteban Gutierrez]

Congrats and welcome, Chia-Ping!

--
Cloudera, Inc.


On Sun, Mar 19, 2017 at 6:18 PM, Guanghao Zhang  wrote:

> Congratulations！
>
> 2017-03-20 9:08 GMT+08:00 宾莉金 or binlijin :
>
> > Congratulations and welcome!
> >
> > 2017-03-19 15:43 GMT+08:00 Phil Yang :
> >
> > > Congratulations!
> > >
> > > Thanks,
> > > Phil
> > >
> > >
> > > 2017-03-18 20:38 GMT+08:00 Ashish Singhi  com
> > >:
> > >
> > > > Many Congratulations !
> > > >
> > > > On Sat, Mar 18, 2017 at 4:00 AM, Anoop John 
> > > wrote:
> > > >
> > > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> > > > Chia-Ping
> > > > > Tsai
> > > > > has accepted the PMC's invitation to become a committer on the
> > project.
> > > > We
> > > > > appreciate all of his contributions thus far and look forward
> > > > > to his continued involvement.
> > > > >
> > > > > Congratulation and welcome Chia-Ping Tsai!
> > > > >
> > > > > -Anoop-
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Best Regards,*
> >  lijin bin
> >
>

Re: [ANNOUNCE] New HBase committer Chia-Ping Tsai

[Huaxiang Sun]

Congratulations, Chia-Ping!

> On Mar 18, 2017, at 5:38 AM, Ashish Singhi  
> wrote:
> 
> Many Congratulations !
> 
> On Sat, Mar 18, 2017 at 4:00 AM, Anoop John  wrote:
> 
>> On behalf of the Apache HBase PMC, I am pleased to announce that Chia-Ping
>> Tsai
>> has accepted the PMC's invitation to become a committer on the project. We
>> appreciate all of his contributions thus far and look forward
>> to his continued involvement.
>> 
>> Congratulation and welcome Chia-Ping Tsai!
>> 
>> -Anoop-
>> 

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/522/artifact/website.patch.zip
 | funzip > 4088f822a449acc39c2408a287f820ec26acabf4.patch
  git fetch
  git checkout -b asf-site-4088f822a449acc39c2408a287f820ec26acabf4 
origin/asf-site
  git am --whitespace=fix 4088f822a449acc39c2408a287f820ec26acabf4.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-4088f822a449acc39c2408a287f820ec26acabf4 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-4088f822a449acc39c2408a287f820ec26acabf4:asf-site
  git checkout asf-site
  git branch -D asf-site-4088f822a449acc39c2408a287f820ec26acabf4

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/522/console

Re: [ANNOUNCE] New HBase committer Chia-Ping Tsai

[ramkrishna vasudevan]

Congratulations !!!

On Mon, Mar 20, 2017 at 10:43 PM, Huaxiang Sun  wrote:

> Congratulations, Chia-Ping!
>
> > On Mar 18, 2017, at 5:38 AM, Ashish Singhi  com> wrote:
> >
> > Many Congratulations !
> >
> > On Sat, Mar 18, 2017 at 4:00 AM, Anoop John 
> wrote:
> >
> >> On behalf of the Apache HBase PMC, I am pleased to announce that
> Chia-Ping
> >> Tsai
> >> has accepted the PMC's invitation to become a committer on the project.
> We
> >> appreciate all of his contributions thus far and look forward
> >> to his continued involvement.
> >>
> >> Congratulation and welcome Chia-Ping Tsai!
> >>
> >> -Anoop-
> >>
>
>

Re: About the InterfaceStability annotation for public API

[Yu Li]

+1 on removing InterfaceStability annotation for IA.Public. Even more, is
it possible to forbid using these two annotations together in Yetus at
code-level if we are migrating to it (as mentioned in another thread)?

For IA.Private or IA.LimitedPrivate, personally I think InterfaceStability
is still a useful annotation.

Best Regards,
Yu

On 20 March 2017 at 22:07, Sean Busbey  wrote:

> I really dislike having InterfaceStability markings on IA.Public
> interfaces, because to me it reads like us essentially saying we
> didn't invest enough time in deciding what something should look like
> before declaring it safe for downstream folks. If someone is
> comfortable with the risk of an API that can change in minor or
> maintenance releases, what's gained by calling it IA.Public +
> IS.Evolving or Unstable rather than just labeling it IA.Private or
> IA.LimitedPrivate?
>
> So I'd be +1 on updating our docs to state that InterfaceStability is
> just for IA.LimitedPrivate or even discontinuing our use of it
> entirely.
>
> On Sun, Mar 19, 2017 at 11:28 PM, Duo Zhang  wrote:
> > In the compatibility section of our refguide, the compatibility for patch
> > version, minor version and major version is not related
> > to InterfaceStability annotation. The only place we mention it is for
> > Server-Side Limited API compatibility.
> >
> > And  in the Developer Guidelines section, we say this
> > @InterfaceStability.Evolving
> >
> > Public packages marked as evolving may be changed, but it is discouraged.
> > I think this is a little confusing, esepecially that the comment
> > of InterfaceStability also mentions the compatibility for patch, minor
> and
> > major release.
> >
> > For me, I think only InterfaceStability.Unstable is useful for public
> API.
> > It means the API is still experimental and will not respect the
> > compatibility rule.
> >
> > So here I suggest we just remove the InterfaceStability annoation for the
> > classes which are marked as InterfaceAudience.Public, and change the
> > comment of InterfaceStability and also the refguide to be more specific.
> >
> > Suggestions are welcomed.
> >
> > Thanks.
>

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/523/artifact/website.patch.zip
 | funzip > 55d6dcaf877cc5223e679736eb613173229c18be.patch
  git fetch
  git checkout -b asf-site-55d6dcaf877cc5223e679736eb613173229c18be 
origin/asf-site
  git am --whitespace=fix 55d6dcaf877cc5223e679736eb613173229c18be.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-55d6dcaf877cc5223e679736eb613173229c18be branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-55d6dcaf877cc5223e679736eb613173229c18be:asf-site
  git checkout asf-site
  git branch -D asf-site-55d6dcaf877cc5223e679736eb613173229c18be

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/523/console