Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

So looking at restoring the method and adding a deprecation to
ByteBufferUtils (HBASE-22504), I discovered HBASE-22044. This class is
getting a short-circuit deprecation cycle, so we only need to restore the
method to branch-2 and branch-2.3. Our API compatibility tool didn't flag
this at all!

On Wed, Jun 24, 2020 at 2:04 PM Nick Dimiduk  wrote:

> It appears there was a decision made on HBASE-20149 to exclude the dev and
> testdev api docs from the main tarball on HBASE-20149. This was not
> replicated for the client assembly.
>
> https://github.com/apache/hbase/pull/1964
>
> On Wed, Jun 24, 2020 at 1:07 PM Nick Dimiduk  wrote:
>
>> Seems we simply didn't ship documentation in the client tarball with
>> 2.2.5.
>>
>> Do we want to ship docs in the client tarball? It seems like we should.
>>
>> Do we want to ship all these variants of the docs in the client tarball?
>> I'm not so sure.
>>
>> On Wed, Jun 24, 2020 at 12:27 PM Nick Dimiduk  wrote:
>>
>>> On Wed, Jun 17, 2020 at 11:31 PM 张铎(Duo Zhang) 
>>> wrote:
>>>
 My only concerns is that, the client-bin is even larger than the bin,
 308
 MB vs 260 MB. Is this expected? The main difference is the docs
 directory,
 in bin it is 65 MB while in client-bin it is 681 MB.

>>>
>>> This was surprising for me as well. I opened HBASE-24629 to dig into it.
>>>
>>> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：

 > I'm still testing but let me post something about the compatibility
 report
 > first.
 >
 > There is an incompatible item about removing a method from the Admin
 > interface, which should not happen for a minor release.
 >
 > package org.apache.hadoop.hbase.client
 > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
 >
 >
 org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
 >
 > Checked the release note and found out that it was done in
 HBASE-22001, by
 > me...
 > I just changed the return value from void to Future, so the
 > compatibility report tells that the method which returns void has been
 > removed.
 >
 > I think this is fine. We do not guarantee drop in replacement for a
 minor
 > release, and it will not be a problem if users recompile their code.
 >
 > Thanks.
 >
 > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
 >
 >> Thanks. I'm switching my vote to +1.
 >>
 >> - Signatures match (src/bin)
 >> - Checksums match (src/bin)
 >> - Compiled src from scratch
 >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
 >> - Started a local mini cluster from compiled-src and bin artifacts
 and ran
 >> some smoke tests - No issues
 >> - Skimmed through the release notes.
 >>
 >> Thanks Nick for putting together such a high quality release,
 especially
 >> all the work around docs/test flakes etc.
 >>
 >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
 >> wrote:
 >>
 >> > I have updated the KEYS file with revision 40069.
 >> >
 >> > I have also verified the content of the file on people.apache.org
 is
 >> up to
 >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
 >> >
 >> > Thanks,
 >> > Nick
 >> >
 >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
 >> wrote:
 >> >
 >> > > Ah, could be. I did update the expiration date. Let me update
 the KEYS
 >> > > file and double-check id.a.o.
 >> > >
 >> > > Thanks for the reminder.
 >> > >
 >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
 >> bhara...@apache.org>
 >> > > wrote:
 >> > >
 >> > >> -1 (binding)
 >> > >>
 >> > >> Looks like your key from the KEYS file has expired?  Per Apache
 FAQs
 >> > >> ,
 "A
 >> > >> signature is valid, if gpg verifies the .asc as a good
 signature, and
 >> > >> doesn't complain about expired or revoked keys."
 >> > >>
 >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
 >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
 >> > >> > gpg:using RSA key
 >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
 >> > >> > gpg:issuer "ndimi...@apache.org"
 >> > >> > gpg: Good signature from "Nick Dimiduk "
 >> > [expired]
 >> > >> > gpg: aka "Nick Dimiduk "
 >> > [expired]
 >> > >> > gpg: Note: This key has expired!
 >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36
 33F1
 >> 8644
 >> > >> EEB6
 >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90
 3907
 >> 1C34
 >> > >> 89BD
 >> > >>
 >> > >>
 >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk <
 ndimi...@apache.org>
 >> > wrote:
 >> > 

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

It appears there was a decision made on HBASE-20149 to exclude the dev and
testdev api docs from the main tarball on HBASE-20149. This was not
replicated for the client assembly.

https://github.com/apache/hbase/pull/1964

On Wed, Jun 24, 2020 at 1:07 PM Nick Dimiduk  wrote:

> Seems we simply didn't ship documentation in the client tarball with 2.2.5.
>
> Do we want to ship docs in the client tarball? It seems like we should.
>
> Do we want to ship all these variants of the docs in the client tarball?
> I'm not so sure.
>
> On Wed, Jun 24, 2020 at 12:27 PM Nick Dimiduk  wrote:
>
>> On Wed, Jun 17, 2020 at 11:31 PM 张铎(Duo Zhang) 
>> wrote:
>>
>>> My only concerns is that, the client-bin is even larger than the bin, 308
>>> MB vs 260 MB. Is this expected? The main difference is the docs
>>> directory,
>>> in bin it is 65 MB while in client-bin it is 681 MB.
>>>
>>
>> This was surprising for me as well. I opened HBASE-24629 to dig into it.
>>
>> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>>>
>>> > I'm still testing but let me post something about the compatibility
>>> report
>>> > first.
>>> >
>>> > There is an incompatible item about removing a method from the Admin
>>> > interface, which should not happen for a minor release.
>>> >
>>> > package org.apache.hadoop.hbase.client
>>> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
>>> >
>>> >
>>> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
>>> >
>>> > Checked the release note and found out that it was done in
>>> HBASE-22001, by
>>> > me...
>>> > I just changed the return value from void to Future, so the
>>> > compatibility report tells that the method which returns void has been
>>> > removed.
>>> >
>>> > I think this is fine. We do not guarantee drop in replacement for a
>>> minor
>>> > release, and it will not be a problem if users recompile their code.
>>> >
>>> > Thanks.
>>> >
>>> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
>>> >
>>> >> Thanks. I'm switching my vote to +1.
>>> >>
>>> >> - Signatures match (src/bin)
>>> >> - Checksums match (src/bin)
>>> >> - Compiled src from scratch
>>> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
>>> >> - Started a local mini cluster from compiled-src and bin artifacts
>>> and ran
>>> >> some smoke tests - No issues
>>> >> - Skimmed through the release notes.
>>> >>
>>> >> Thanks Nick for putting together such a high quality release,
>>> especially
>>> >> all the work around docs/test flakes etc.
>>> >>
>>> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
>>> >> wrote:
>>> >>
>>> >> > I have updated the KEYS file with revision 40069.
>>> >> >
>>> >> > I have also verified the content of the file on people.apache.org
>>> is
>>> >> up to
>>> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
>>> >> >
>>> >> > Thanks,
>>> >> > Nick
>>> >> >
>>> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
>>> >> wrote:
>>> >> >
>>> >> > > Ah, could be. I did update the expiration date. Let me update the
>>> KEYS
>>> >> > > file and double-check id.a.o.
>>> >> > >
>>> >> > > Thanks for the reminder.
>>> >> > >
>>> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
>>> >> bhara...@apache.org>
>>> >> > > wrote:
>>> >> > >
>>> >> > >> -1 (binding)
>>> >> > >>
>>> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
>>> FAQs
>>> >> > >> ,
>>> "A
>>> >> > >> signature is valid, if gpg verifies the .asc as a good
>>> signature, and
>>> >> > >> doesn't complain about expired or revoked keys."
>>> >> > >>
>>> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
>>> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
>>> >> > >> > gpg:using RSA key
>>> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
>>> >> > >> > gpg:issuer "ndimi...@apache.org"
>>> >> > >> > gpg: Good signature from "Nick Dimiduk "
>>> >> > [expired]
>>> >> > >> > gpg: aka "Nick Dimiduk "
>>> >> > [expired]
>>> >> > >> > gpg: Note: This key has expired!
>>> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36
>>> 33F1
>>> >> 8644
>>> >> > >> EEB6
>>> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90
>>> 3907
>>> >> 1C34
>>> >> > >> 89BD
>>> >> > >>
>>> >> > >>
>>> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk <
>>> ndimi...@apache.org>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> > Please vote on this Apache hbase release candidate,
>>> >> > >> > hbase-2.3.0RC0
>>> >> > >> >
>>> >> > >> > The VOTE will remain open for at least 72 hours.
>>> >> > >> >
>>> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
>>> >> > >> > [ ] -1 Do not release this package because ...
>>> >> > >> >
>>> >> > >> > The tag to be voted on is 2.3.0RC0:
>>> >> > >> >
>>> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
>>> >> > >> >
>>> >> > >> > The release fi

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Seems we simply didn't ship documentation in the client tarball with 2.2.5.

Do we want to ship docs in the client tarball? It seems like we should.

Do we want to ship all these variants of the docs in the client tarball?
I'm not so sure.

On Wed, Jun 24, 2020 at 12:27 PM Nick Dimiduk  wrote:

> On Wed, Jun 17, 2020 at 11:31 PM 张铎(Duo Zhang) 
> wrote:
>
>> My only concerns is that, the client-bin is even larger than the bin, 308
>> MB vs 260 MB. Is this expected? The main difference is the docs directory,
>> in bin it is 65 MB while in client-bin it is 681 MB.
>>
>
> This was surprising for me as well. I opened HBASE-24629 to dig into it.
>
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>>
>> > I'm still testing but let me post something about the compatibility
>> report
>> > first.
>> >
>> > There is an incompatible item about removing a method from the Admin
>> > interface, which should not happen for a minor release.
>> >
>> > package org.apache.hadoop.hbase.client
>> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
>> >
>> >
>> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
>> >
>> > Checked the release note and found out that it was done in HBASE-22001,
>> by
>> > me...
>> > I just changed the return value from void to Future, so the
>> > compatibility report tells that the method which returns void has been
>> > removed.
>> >
>> > I think this is fine. We do not guarantee drop in replacement for a
>> minor
>> > release, and it will not be a problem if users recompile their code.
>> >
>> > Thanks.
>> >
>> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
>> >
>> >> Thanks. I'm switching my vote to +1.
>> >>
>> >> - Signatures match (src/bin)
>> >> - Checksums match (src/bin)
>> >> - Compiled src from scratch
>> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
>> >> - Started a local mini cluster from compiled-src and bin artifacts and
>> ran
>> >> some smoke tests - No issues
>> >> - Skimmed through the release notes.
>> >>
>> >> Thanks Nick for putting together such a high quality release,
>> especially
>> >> all the work around docs/test flakes etc.
>> >>
>> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
>> >> wrote:
>> >>
>> >> > I have updated the KEYS file with revision 40069.
>> >> >
>> >> > I have also verified the content of the file on people.apache.org is
>> >> up to
>> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
>> >> >
>> >> > Thanks,
>> >> > Nick
>> >> >
>> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
>> >> wrote:
>> >> >
>> >> > > Ah, could be. I did update the expiration date. Let me update the
>> KEYS
>> >> > > file and double-check id.a.o.
>> >> > >
>> >> > > Thanks for the reminder.
>> >> > >
>> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
>> >> bhara...@apache.org>
>> >> > > wrote:
>> >> > >
>> >> > >> -1 (binding)
>> >> > >>
>> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
>> FAQs
>> >> > >> ,
>> "A
>> >> > >> signature is valid, if gpg verifies the .asc as a good signature,
>> and
>> >> > >> doesn't complain about expired or revoked keys."
>> >> > >>
>> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
>> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
>> >> > >> > gpg:using RSA key
>> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
>> >> > >> > gpg:issuer "ndimi...@apache.org"
>> >> > >> > gpg: Good signature from "Nick Dimiduk "
>> >> > [expired]
>> >> > >> > gpg: aka "Nick Dimiduk "
>> >> > [expired]
>> >> > >> > gpg: Note: This key has expired!
>> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36
>> 33F1
>> >> 8644
>> >> > >> EEB6
>> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90
>> 3907
>> >> 1C34
>> >> > >> 89BD
>> >> > >>
>> >> > >>
>> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk > >
>> >> > wrote:
>> >> > >>
>> >> > >> > Please vote on this Apache hbase release candidate,
>> >> > >> > hbase-2.3.0RC0
>> >> > >> >
>> >> > >> > The VOTE will remain open for at least 72 hours.
>> >> > >> >
>> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
>> >> > >> > [ ] -1 Do not release this package because ...
>> >> > >> >
>> >> > >> > The tag to be voted on is 2.3.0RC0:
>> >> > >> >
>> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
>> >> > >> >
>> >> > >> > The release files, including signatures, digests, as well as
>> >> > CHANGES.md
>> >> > >> > and RELEASENOTES.md included in this RC can be found at:
>> >> > >> >
>> >> > >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>> >> > >> >
>> >> > >> > Maven artifacts are available in a staging repository at:
>> >> > >> >
>> >> > >> >
>> >> > >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachehbase-1393/
>> >> > >> >
>> >> > >> > A

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

On Wed, Jun 17, 2020 at 11:31 PM 张铎(Duo Zhang) 
wrote:

> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
>

This was surprising for me as well. I opened HBASE-24629 to dig into it.

张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>
> > I'm still testing but let me post something about the compatibility
> report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001,
> by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and
> ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.org"
> >> > >> > gpg: Good signature from "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: aka "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: Note: This key has expired!
> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
> >> 8644
> >> > >> EEB6
> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
> >> 1C34
> >> > >> 89BD
> >> > >>
> >> > >>
> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> >> > wrote:
> >> > >>
> >> > >> > Please vote on this Apache hbase release candidate,
> >> > >> > hbase-2.3.0RC0
> >> > >> >
> >> > >> > The VOTE will remain open for at least 72 hours.
> >> > >> >
> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
> >> > >> > [ ] -1 Do not release this package because ...
> >> > >> >
> >> > >> > The tag to be voted on is 2.3.0RC0:
> >> > >> >
> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >> > >> >
> >> > >> > The release files, including signatures, digests, as well as
> >> > CHANGES.md
> >> > >> > and RELEASENOTES.md included in this RC can be found at:
> >> > >> >
> >> > >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >> > >> >
> >> > >> > Maven artifacts are available in a staging repository at:
> >> > >> >
> >> > >> >
> >> > >>
> >> https://repository.apache.org/content/repositories/orgapachehbase-1393/
> >> > >> >
> >> > >> > Artifacts were signed with the ndimi...@apache.org key which can
> >> be
> >> > >> found
> >> > >> > in:
> >> > >> >
> >> > >> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> >> > >> >
> >> > >> > To learn more about Apache hbase, please see
> >> > >> >
> >> > >> >   http://hbase.apache.org/
> >> > >> >
> >> > >> > Thanks,
> >> > >> > Your HBase Release Manager
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
> >
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

On Wed, Jun 24, 2020 at 8:11 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:

> I guess following the [DISCUSS] thread, we also need to bring back original
> signature for
> "org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad"?
>

That is what I have proposed, yes.

Em seg., 22 de jun. de 2020 às 19:22, Wellington Chevreuil <
> wellington.chevre...@gmail.com> escreveu:
>
> > Had submitted an addendum PR for HBASE-21773. For HBASE-24221, we may try
> > the same.
> >
> > Em seg., 22 de jun. de 2020 às 17:45, Nick Dimiduk 
> > escreveu:
> >
> >> I have reopened HBASE-22504, HBASE-21773, HBASE-23055, and HBASE-24102
> for
> >> addendums based on this thread. I also started a [DISCUSS] thread re:
> >> VisibleForTesting annotation.
> >>
> >> Thanks,
> >> Nick
> >>
> >> On Mon, Jun 22, 2020 at 9:22 AM Nick Dimiduk 
> wrote:
> >>
> >> > > On NettyRpcClientConfigHelper I think it is fine. It is designed to
> be
> >> > an 'util' class, so in HBASE-23956 we made it final and added a
> private
> >> > constructor. It only has static methods and is not expected to be
> >> extended
> >> > or instantiated by end users.
> >> >
> >> > Very well, let's keep this change.
> >> >
> >> > > On ByteBufferUtils, it is IA.Private on master branch?
> >> >
> >> > It is IA.Public on 2.2.0, the point of reference.
> >> >
> >> > > On the replication related classes, all the constructors are marked
> as
> >> > IA.Private, so I think they are all fine. Anyway, we should have a
> >> better
> >> > design, maybe something like the ClusterMetrics, where we introduce an
> >> > interface get the metrics.
> >> >
> >> > Ah indeed, the constructors are marked IA.Private. That's not very
> kind
> >> to
> >> > our users, but I guess it works.
> >> >
> >> > > For the
> >> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> >> > change added by HBASE-24221, the method is marked with
> >> @VisibleForTesting
> >> > and javadoc says "Protected for testing", so maybe it's fine?
> >> >
> >> > To the best of my knowledge, we do not discuss the @VisibleForTesting
> >> > annotation in our compatibility guidelines, thus I think it's a
> >> violation.
> >> >
> >> > > For
> "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
> >> > -- Method parameter removed via HBASE-21773" and
> >> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> >> > constructor arguments added in HBASE-22648" I guess we could push
> >> amending
> >> > PRs re-adding the methods with original signature as deprecated?
> >> >
> >> > Yes, sounds good for both of them.
> >> >
> >> > > adding property map argument in SnapshotDescription was my doing,
> let
> >> me
> >> > open up Jira to bring back original signature as deprecated (since I
> am
> >> > familiar with it). I can also help look into other changes if
> required.
> >> >
> >> > Thank you!
> >> >
> >> > > Moreover, reg test failure for ReplicationStatusSink, opened Jira
> >> > HBASE-24594 to have it separate cluster pair setup and not share
> >> resources
> >> > with TestReplicationStatus. This is committed, I will keep an eye on
> >> flaky
> >> > and nightly builds.
> >> >
> >> > And thank you again :)
> >> >
> >> > On Sun, Jun 21, 2020 at 10:52 AM Viraj Jasani 
> >> wrote:
> >> >
> >> >> Nick,
> >> >>
> >> >> I just went through above methods and I agree with Duo and Wellington
> >> reg
> >> >> @IA.Private, @VisibleForTesting methods and also the fact that we
> >> should
> >> >> add original signature for IA.Public methods making them deprecated
> and
> >> >> internally using new methods. e.g adding property map argument in
> >> >> SnapshotDescription was my doing, let me open up Jira to bring back
> >> >> original signature as deprecated (since I am familiar with it). I can
> >> also
> >> >> help look into other changes if required.
> >> >>
> >> >> Moreover, reg test failure for ReplicationStatusSink, opened Jira
> >> >> HBASE-24594 to have it separate cluster pair setup and not share
> >> resources
> >> >> with TestReplicationStatus. This is committed, I will keep an eye on
> >> flaky
> >> >> and nightly builds. I wish I had taken junit xml output when it
> failed,
> >> >> apologies. However, I am glad that this is not reported flaky as such
> >> and
> >> >> with separate resource allocation, this should go even smoother.
> >> >>
> >> >> Overall, I am hopeful that we should be able to take care of all
> >> relevant
> >> >> source incompatibilities sooner.
> >> >>
> >> >>
> >> >> On 2020/06/19 09:51:43, Wellington Chevreuil <
> >> >> wellington.chevre...@gmail.com> wrote:
> >> >> > I agree with Duo regarding the methods that were already marked as
> >> >> > IA.private.
> >> >> >
> >> >> > For the
> >> >> >
> >> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> >> >> > change added by HBASE-24221, the method is marked with
> >> >> @VisibleForTesting
> >> >> > and javadoc says "Protected for testing", so maybe it's fine?
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Wellington Chevreuil]

I guess following the [DISCUSS] thread, we also need to bring back original
signature for
"org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad"?

Em seg., 22 de jun. de 2020 às 19:22, Wellington Chevreuil <
wellington.chevre...@gmail.com> escreveu:

> Had submitted an addendum PR for HBASE-21773. For HBASE-24221, we may try
> the same.
>
> Em seg., 22 de jun. de 2020 às 17:45, Nick Dimiduk 
> escreveu:
>
>> I have reopened HBASE-22504, HBASE-21773, HBASE-23055, and HBASE-24102 for
>> addendums based on this thread. I also started a [DISCUSS] thread re:
>> VisibleForTesting annotation.
>>
>> Thanks,
>> Nick
>>
>> On Mon, Jun 22, 2020 at 9:22 AM Nick Dimiduk  wrote:
>>
>> > > On NettyRpcClientConfigHelper I think it is fine. It is designed to be
>> > an 'util' class, so in HBASE-23956 we made it final and added a private
>> > constructor. It only has static methods and is not expected to be
>> extended
>> > or instantiated by end users.
>> >
>> > Very well, let's keep this change.
>> >
>> > > On ByteBufferUtils, it is IA.Private on master branch?
>> >
>> > It is IA.Public on 2.2.0, the point of reference.
>> >
>> > > On the replication related classes, all the constructors are marked as
>> > IA.Private, so I think they are all fine. Anyway, we should have a
>> better
>> > design, maybe something like the ClusterMetrics, where we introduce an
>> > interface get the metrics.
>> >
>> > Ah indeed, the constructors are marked IA.Private. That's not very kind
>> to
>> > our users, but I guess it works.
>> >
>> > > For the
>> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
>> > change added by HBASE-24221, the method is marked with
>> @VisibleForTesting
>> > and javadoc says "Protected for testing", so maybe it's fine?
>> >
>> > To the best of my knowledge, we do not discuss the @VisibleForTesting
>> > annotation in our compatibility guidelines, thus I think it's a
>> violation.
>> >
>> > > For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
>> > -- Method parameter removed via HBASE-21773" and
>> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
>> > constructor arguments added in HBASE-22648" I guess we could push
>> amending
>> > PRs re-adding the methods with original signature as deprecated?
>> >
>> > Yes, sounds good for both of them.
>> >
>> > > adding property map argument in SnapshotDescription was my doing, let
>> me
>> > open up Jira to bring back original signature as deprecated (since I am
>> > familiar with it). I can also help look into other changes if required.
>> >
>> > Thank you!
>> >
>> > > Moreover, reg test failure for ReplicationStatusSink, opened Jira
>> > HBASE-24594 to have it separate cluster pair setup and not share
>> resources
>> > with TestReplicationStatus. This is committed, I will keep an eye on
>> flaky
>> > and nightly builds.
>> >
>> > And thank you again :)
>> >
>> > On Sun, Jun 21, 2020 at 10:52 AM Viraj Jasani 
>> wrote:
>> >
>> >> Nick,
>> >>
>> >> I just went through above methods and I agree with Duo and Wellington
>> reg
>> >> @IA.Private, @VisibleForTesting methods and also the fact that we
>> should
>> >> add original signature for IA.Public methods making them deprecated and
>> >> internally using new methods. e.g adding property map argument in
>> >> SnapshotDescription was my doing, let me open up Jira to bring back
>> >> original signature as deprecated (since I am familiar with it). I can
>> also
>> >> help look into other changes if required.
>> >>
>> >> Moreover, reg test failure for ReplicationStatusSink, opened Jira
>> >> HBASE-24594 to have it separate cluster pair setup and not share
>> resources
>> >> with TestReplicationStatus. This is committed, I will keep an eye on
>> flaky
>> >> and nightly builds. I wish I had taken junit xml output when it failed,
>> >> apologies. However, I am glad that this is not reported flaky as such
>> and
>> >> with separate resource allocation, this should go even smoother.
>> >>
>> >> Overall, I am hopeful that we should be able to take care of all
>> relevant
>> >> source incompatibilities sooner.
>> >>
>> >>
>> >> On 2020/06/19 09:51:43, Wellington Chevreuil <
>> >> wellington.chevre...@gmail.com> wrote:
>> >> > I agree with Duo regarding the methods that were already marked as
>> >> > IA.private.
>> >> >
>> >> > For the
>> >> >
>> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
>> >> > change added by HBASE-24221, the method is marked with
>> >> @VisibleForTesting
>> >> > and javadoc says "Protected for testing", so maybe it's fine?
>> >> >
>> >> > For
>> "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
>> >> > --Method parameter removed via HBASE-21773" and
>> >> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
>> >> > constructor arguments added in HBASE-22648" I guess we could
>> >> > push amending PRs re-adding the methods with original signature as
>> >> > deprecated?
>> >> >
>> 

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Wellington Chevreuil]

Had submitted an addendum PR for HBASE-21773. For HBASE-24221, we may try
the same.

Em seg., 22 de jun. de 2020 às 17:45, Nick Dimiduk 
escreveu:

> I have reopened HBASE-22504, HBASE-21773, HBASE-23055, and HBASE-24102 for
> addendums based on this thread. I also started a [DISCUSS] thread re:
> VisibleForTesting annotation.
>
> Thanks,
> Nick
>
> On Mon, Jun 22, 2020 at 9:22 AM Nick Dimiduk  wrote:
>
> > > On NettyRpcClientConfigHelper I think it is fine. It is designed to be
> > an 'util' class, so in HBASE-23956 we made it final and added a private
> > constructor. It only has static methods and is not expected to be
> extended
> > or instantiated by end users.
> >
> > Very well, let's keep this change.
> >
> > > On ByteBufferUtils, it is IA.Private on master branch?
> >
> > It is IA.Public on 2.2.0, the point of reference.
> >
> > > On the replication related classes, all the constructors are marked as
> > IA.Private, so I think they are all fine. Anyway, we should have a better
> > design, maybe something like the ClusterMetrics, where we introduce an
> > interface get the metrics.
> >
> > Ah indeed, the constructors are marked IA.Private. That's not very kind
> to
> > our users, but I guess it works.
> >
> > > For the
> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> > change added by HBASE-24221, the method is marked with @VisibleForTesting
> > and javadoc says "Protected for testing", so maybe it's fine?
> >
> > To the best of my knowledge, we do not discuss the @VisibleForTesting
> > annotation in our compatibility guidelines, thus I think it's a
> violation.
> >
> > > For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
> > -- Method parameter removed via HBASE-21773" and
> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> > constructor arguments added in HBASE-22648" I guess we could push
> amending
> > PRs re-adding the methods with original signature as deprecated?
> >
> > Yes, sounds good for both of them.
> >
> > > adding property map argument in SnapshotDescription was my doing, let
> me
> > open up Jira to bring back original signature as deprecated (since I am
> > familiar with it). I can also help look into other changes if required.
> >
> > Thank you!
> >
> > > Moreover, reg test failure for ReplicationStatusSink, opened Jira
> > HBASE-24594 to have it separate cluster pair setup and not share
> resources
> > with TestReplicationStatus. This is committed, I will keep an eye on
> flaky
> > and nightly builds.
> >
> > And thank you again :)
> >
> > On Sun, Jun 21, 2020 at 10:52 AM Viraj Jasani 
> wrote:
> >
> >> Nick,
> >>
> >> I just went through above methods and I agree with Duo and Wellington
> reg
> >> @IA.Private, @VisibleForTesting methods and also the fact that we should
> >> add original signature for IA.Public methods making them deprecated and
> >> internally using new methods. e.g adding property map argument in
> >> SnapshotDescription was my doing, let me open up Jira to bring back
> >> original signature as deprecated (since I am familiar with it). I can
> also
> >> help look into other changes if required.
> >>
> >> Moreover, reg test failure for ReplicationStatusSink, opened Jira
> >> HBASE-24594 to have it separate cluster pair setup and not share
> resources
> >> with TestReplicationStatus. This is committed, I will keep an eye on
> flaky
> >> and nightly builds. I wish I had taken junit xml output when it failed,
> >> apologies. However, I am glad that this is not reported flaky as such
> and
> >> with separate resource allocation, this should go even smoother.
> >>
> >> Overall, I am hopeful that we should be able to take care of all
> relevant
> >> source incompatibilities sooner.
> >>
> >>
> >> On 2020/06/19 09:51:43, Wellington Chevreuil <
> >> wellington.chevre...@gmail.com> wrote:
> >> > I agree with Duo regarding the methods that were already marked as
> >> > IA.private.
> >> >
> >> > For the
> >> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> >> > change added by HBASE-24221, the method is marked with
> >> @VisibleForTesting
> >> > and javadoc says "Protected for testing", so maybe it's fine?
> >> >
> >> > For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
> >> > --Method parameter removed via HBASE-21773" and
> >> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> >> > constructor arguments added in HBASE-22648" I guess we could
> >> > push amending PRs re-adding the methods with original signature as
> >> > deprecated?
> >> >
> >> >
> >> >
> >> > Em sex., 19 de jun. de 2020 às 03:01, 张铎(Duo Zhang) <
> >> palomino...@gmail.com>
> >> > escreveu:
> >> >
> >> > > On NettyRpcClientConfigHelper I think it is fine. It is designed to
> >> be an
> >> > > 'util' class, so in HBASE-23956 we made it final and added a private
> >> > > constructor. It only has static methods and is not expected to be
> >> extended
> >> > > or instantiated by

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

I have reopened HBASE-22504, HBASE-21773, HBASE-23055, and HBASE-24102 for
addendums based on this thread. I also started a [DISCUSS] thread re:
VisibleForTesting annotation.

Thanks,
Nick

On Mon, Jun 22, 2020 at 9:22 AM Nick Dimiduk  wrote:

> > On NettyRpcClientConfigHelper I think it is fine. It is designed to be
> an 'util' class, so in HBASE-23956 we made it final and added a private
> constructor. It only has static methods and is not expected to be extended
> or instantiated by end users.
>
> Very well, let's keep this change.
>
> > On ByteBufferUtils, it is IA.Private on master branch?
>
> It is IA.Public on 2.2.0, the point of reference.
>
> > On the replication related classes, all the constructors are marked as
> IA.Private, so I think they are all fine. Anyway, we should have a better
> design, maybe something like the ClusterMetrics, where we introduce an
> interface get the metrics.
>
> Ah indeed, the constructors are marked IA.Private. That's not very kind to
> our users, but I guess it works.
>
> > For the
> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> change added by HBASE-24221, the method is marked with @VisibleForTesting
> and javadoc says "Protected for testing", so maybe it's fine?
>
> To the best of my knowledge, we do not discuss the @VisibleForTesting
> annotation in our compatibility guidelines, thus I think it's a violation.
>
> > For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
> -- Method parameter removed via HBASE-21773" and
> "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> constructor arguments added in HBASE-22648" I guess we could push amending
> PRs re-adding the methods with original signature as deprecated?
>
> Yes, sounds good for both of them.
>
> > adding property map argument in SnapshotDescription was my doing, let me
> open up Jira to bring back original signature as deprecated (since I am
> familiar with it). I can also help look into other changes if required.
>
> Thank you!
>
> > Moreover, reg test failure for ReplicationStatusSink, opened Jira
> HBASE-24594 to have it separate cluster pair setup and not share resources
> with TestReplicationStatus. This is committed, I will keep an eye on flaky
> and nightly builds.
>
> And thank you again :)
>
> On Sun, Jun 21, 2020 at 10:52 AM Viraj Jasani  wrote:
>
>> Nick,
>>
>> I just went through above methods and I agree with Duo and Wellington reg
>> @IA.Private, @VisibleForTesting methods and also the fact that we should
>> add original signature for IA.Public methods making them deprecated and
>> internally using new methods. e.g adding property map argument in
>> SnapshotDescription was my doing, let me open up Jira to bring back
>> original signature as deprecated (since I am familiar with it). I can also
>> help look into other changes if required.
>>
>> Moreover, reg test failure for ReplicationStatusSink, opened Jira
>> HBASE-24594 to have it separate cluster pair setup and not share resources
>> with TestReplicationStatus. This is committed, I will keep an eye on flaky
>> and nightly builds. I wish I had taken junit xml output when it failed,
>> apologies. However, I am glad that this is not reported flaky as such and
>> with separate resource allocation, this should go even smoother.
>>
>> Overall, I am hopeful that we should be able to take care of all relevant
>> source incompatibilities sooner.
>>
>>
>> On 2020/06/19 09:51:43, Wellington Chevreuil <
>> wellington.chevre...@gmail.com> wrote:
>> > I agree with Duo regarding the methods that were already marked as
>> > IA.private.
>> >
>> > For the
>> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
>> > change added by HBASE-24221, the method is marked with
>> @VisibleForTesting
>> > and javadoc says "Protected for testing", so maybe it's fine?
>> >
>> > For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
>> > --Method parameter removed via HBASE-21773" and
>> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
>> > constructor arguments added in HBASE-22648" I guess we could
>> > push amending PRs re-adding the methods with original signature as
>> > deprecated?
>> >
>> >
>> >
>> > Em sex., 19 de jun. de 2020 às 03:01, 张铎(Duo Zhang) <
>> palomino...@gmail.com>
>> > escreveu:
>> >
>> > > On NettyRpcClientConfigHelper I think it is fine. It is designed to
>> be an
>> > > 'util' class, so in HBASE-23956 we made it final and added a private
>> > > constructor. It only has static methods and is not expected to be
>> extended
>> > > or instantiated by end users.
>> > >
>> > > On ByteBufferUtils, it is IA.Private on master branch?
>> > >
>> > > On the replication related classes, all the constructors are marked as
>> > > IA.Private, so I think they are all fine. Anyway, we should have a
>> better
>> > > design, maybe something like the ClusterMetrics, where we introduce an
>> > > interface get the metrics.
>> > >
>> > >
>> > > Nick Dimid

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

> On NettyRpcClientConfigHelper I think it is fine. It is designed to be an
'util' class, so in HBASE-23956 we made it final and added a private
constructor. It only has static methods and is not expected to be extended
or instantiated by end users.

Very well, let's keep this change.

> On ByteBufferUtils, it is IA.Private on master branch?

It is IA.Public on 2.2.0, the point of reference.

> On the replication related classes, all the constructors are marked as
IA.Private, so I think they are all fine. Anyway, we should have a better
design, maybe something like the ClusterMetrics, where we introduce an
interface get the metrics.

Ah indeed, the constructors are marked IA.Private. That's not very kind to
our users, but I guess it works.

> For the
org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
change added by HBASE-24221, the method is marked with @VisibleForTesting
and javadoc says "Protected for testing", so maybe it's fine?

To the best of my knowledge, we do not discuss the @VisibleForTesting
annotation in our compatibility guidelines, thus I think it's a violation.

> For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
Method parameter removed via HBASE-21773" and
"org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
constructor arguments added in HBASE-22648" I guess we could push amending
PRs re-adding the methods with original signature as deprecated?

Yes, sounds good for both of them.

> adding property map argument in SnapshotDescription was my doing, let me
open up Jira to bring back original signature as deprecated (since I am
familiar with it). I can also help look into other changes if required.

Thank you!

> Moreover, reg test failure for ReplicationStatusSink, opened Jira
HBASE-24594 to have it separate cluster pair setup and not share resources
with TestReplicationStatus. This is committed, I will keep an eye on flaky
and nightly builds.

And thank you again :)

On Sun, Jun 21, 2020 at 10:52 AM Viraj Jasani  wrote:

> Nick,
>
> I just went through above methods and I agree with Duo and Wellington reg
> @IA.Private, @VisibleForTesting methods and also the fact that we should
> add original signature for IA.Public methods making them deprecated and
> internally using new methods. e.g adding property map argument in
> SnapshotDescription was my doing, let me open up Jira to bring back
> original signature as deprecated (since I am familiar with it). I can also
> help look into other changes if required.
>
> Moreover, reg test failure for ReplicationStatusSink, opened Jira
> HBASE-24594 to have it separate cluster pair setup and not share resources
> with TestReplicationStatus. This is committed, I will keep an eye on flaky
> and nightly builds. I wish I had taken junit xml output when it failed,
> apologies. However, I am glad that this is not reported flaky as such and
> with separate resource allocation, this should go even smoother.
>
> Overall, I am hopeful that we should be able to take care of all relevant
> source incompatibilities sooner.
>
>
> On 2020/06/19 09:51:43, Wellington Chevreuil <
> wellington.chevre...@gmail.com> wrote:
> > I agree with Duo regarding the methods that were already marked as
> > IA.private.
> >
> > For the
> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> > change added by HBASE-24221, the method is marked with @VisibleForTesting
> > and javadoc says "Protected for testing", so maybe it's fine?
> >
> > For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
> > --Method parameter removed via HBASE-21773" and
> > "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> > constructor arguments added in HBASE-22648" I guess we could
> > push amending PRs re-adding the methods with original signature as
> > deprecated?
> >
> >
> >
> > Em sex., 19 de jun. de 2020 às 03:01, 张铎(Duo Zhang) <
> palomino...@gmail.com>
> > escreveu:
> >
> > > On NettyRpcClientConfigHelper I think it is fine. It is designed to be
> an
> > > 'util' class, so in HBASE-23956 we made it final and added a private
> > > constructor. It only has static methods and is not expected to be
> extended
> > > or instantiated by end users.
> > >
> > > On ByteBufferUtils, it is IA.Private on master branch?
> > >
> > > On the replication related classes, all the constructors are marked as
> > > IA.Private, so I think they are all fine. Anyway, we should have a
> better
> > > design, maybe something like the ClusterMetrics, where we introduce an
> > > interface get the metrics.
> > >
> > >
> > > Nick Dimiduk  于2020年6月19日周五 上午6:26写道：
> > >
> > > > I've done some accounting of the source-incompatible changes. I'm not
> > > > listing every item here, only the ones that I think might raise
> eyebrows
> > > or
> > > > warrant further discussion. Here are my findings.
> > > >
> > > > I think these problems sink the RC. I plan to reopen the various
> tickets
> > > > here and start a discussion with

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Viraj Jasani]

Nick,

I just went through above methods and I agree with Duo and Wellington reg 
@IA.Private, @VisibleForTesting methods and also the fact that we should add 
original signature for IA.Public methods making them deprecated and internally 
using new methods. e.g adding property map argument in SnapshotDescription was 
my doing, let me open up Jira to bring back original signature as deprecated 
(since I am familiar with it). I can also help look into other changes if 
required.

Moreover, reg test failure for ReplicationStatusSink, opened Jira HBASE-24594 
to have it separate cluster pair setup and not share resources with 
TestReplicationStatus. This is committed, I will keep an eye on flaky and 
nightly builds. I wish I had taken junit xml output when it failed, apologies. 
However, I am glad that this is not reported flaky as such and with separate 
resource allocation, this should go even smoother.

Overall, I am hopeful that we should be able to take care of all relevant 
source incompatibilities sooner.


On 2020/06/19 09:51:43, Wellington Chevreuil  
wrote: 
> I agree with Duo regarding the methods that were already marked as
> IA.private.
> 
> For the
> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
> change added by HBASE-24221, the method is marked with @VisibleForTesting
> and javadoc says "Protected for testing", so maybe it's fine?
> 
> For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
> --Method parameter removed via HBASE-21773" and
> "org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> constructor arguments added in HBASE-22648" I guess we could
> push amending PRs re-adding the methods with original signature as
> deprecated?
> 
> 
> 
> Em sex., 19 de jun. de 2020 às 03:01, 张铎(Duo Zhang) 
> escreveu:
> 
> > On NettyRpcClientConfigHelper I think it is fine. It is designed to be an
> > 'util' class, so in HBASE-23956 we made it final and added a private
> > constructor. It only has static methods and is not expected to be extended
> > or instantiated by end users.
> >
> > On ByteBufferUtils, it is IA.Private on master branch?
> >
> > On the replication related classes, all the constructors are marked as
> > IA.Private, so I think they are all fine. Anyway, we should have a better
> > design, maybe something like the ClusterMetrics, where we introduce an
> > interface get the metrics.
> >
> >
> > Nick Dimiduk  于2020年6月19日周五 上午6:26写道：
> >
> > > I've done some accounting of the source-incompatible changes. I'm not
> > > listing every item here, only the ones that I think might raise eyebrows
> > or
> > > warrant further discussion. Here are my findings.
> > >
> > > I think these problems sink the RC. I plan to reopen the various tickets
> > > here and start a discussion with the authors for getting an addendum
> > posted
> > > that addresses the problems. Before I do that, please speak up if you
> > think
> > > anything here I've -1 are actually justified.
> > >
> > > Thanks,
> > > Nick
> > >
> > > Removed Methods:
> > >  * org.apache.hadoop.hbase.rest.client.{RemoteAdmin,RemoteHTable} --
> > these
> > > were dropped intentionally and with discussion via HBASE-24115, +1.
> > >  * org.apache.hadoop.hbase.util.ByteBufferUtils.findCommonPrefix (...) --
> > > looks like this method was refactored away as part of HBASE-22504.
> > However,
> > > it is present in an IA.Public class, so it needs a deprecation cycle
> > before
> > > removal, -1.
> > >  * org.apache.hadoop.hbase.HRegionInfo.compareTo -- the Comparable
> > > implementation was moved up to the interface via default method, so I
> > think
> > > this is acceptable, via HBASE-23753. +1.
> > >  * org.apache.hadoop.hbase.replication.ReplicationLoadSink -- Additional
> > > constructor arguments added in HBASE-21406, -1.
> > >  * org.apache.hadoop.hbase.replication.ReplicationLoadSource --
> > Additional
> > > constructor arguments added in HBASE-21505, -1.
> > >  * org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> > > constructor arguments added in HBASE-22648, -1.
> > >  *
> > >
> > org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad(...)
> > > -- Method signature change on a protected method via HBASE-24221, -1.
> > >  * org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
> > > Method parameter removed via HBASE-21773, -1.
> > >
> > > Problems with Data Types, High Severity:
> > >  * org.apache.hadoop.hbase.HConstants#HBASE_NON_USER_TABLE_DIRS -- Field
> > > removed via HBASE-23055, -1.
> > >  * org.apache.hadoop.hbase.HRegionInfo Removed super-interface
> > > java.lang.Comparable -- same as HBASE-23753 above. Missing
> > > interface moved to the super-interface, preserved. +1.
> > >  * A number of interfaces seeing new methods. These interfaces look like
> > > API we expect a client to consume, not implement. Book says under Client
> > > API compatibility: "New APIs introduced in a patch version will only be
> > > added in a source

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Wellington Chevreuil]

I agree with Duo regarding the methods that were already marked as
IA.private.

For the
org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad
change added by HBASE-24221, the method is marked with @VisibleForTesting
and javadoc says "Protected for testing", so maybe it's fine?

For "org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob
--Method parameter removed via HBASE-21773" and
"org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
constructor arguments added in HBASE-22648" I guess we could
push amending PRs re-adding the methods with original signature as
deprecated?



Em sex., 19 de jun. de 2020 às 03:01, 张铎(Duo Zhang) 
escreveu:

> On NettyRpcClientConfigHelper I think it is fine. It is designed to be an
> 'util' class, so in HBASE-23956 we made it final and added a private
> constructor. It only has static methods and is not expected to be extended
> or instantiated by end users.
>
> On ByteBufferUtils, it is IA.Private on master branch?
>
> On the replication related classes, all the constructors are marked as
> IA.Private, so I think they are all fine. Anyway, we should have a better
> design, maybe something like the ClusterMetrics, where we introduce an
> interface get the metrics.
>
>
> Nick Dimiduk  于2020年6月19日周五 上午6:26写道：
>
> > I've done some accounting of the source-incompatible changes. I'm not
> > listing every item here, only the ones that I think might raise eyebrows
> or
> > warrant further discussion. Here are my findings.
> >
> > I think these problems sink the RC. I plan to reopen the various tickets
> > here and start a discussion with the authors for getting an addendum
> posted
> > that addresses the problems. Before I do that, please speak up if you
> think
> > anything here I've -1 are actually justified.
> >
> > Thanks,
> > Nick
> >
> > Removed Methods:
> >  * org.apache.hadoop.hbase.rest.client.{RemoteAdmin,RemoteHTable} --
> these
> > were dropped intentionally and with discussion via HBASE-24115, +1.
> >  * org.apache.hadoop.hbase.util.ByteBufferUtils.findCommonPrefix (...) --
> > looks like this method was refactored away as part of HBASE-22504.
> However,
> > it is present in an IA.Public class, so it needs a deprecation cycle
> before
> > removal, -1.
> >  * org.apache.hadoop.hbase.HRegionInfo.compareTo -- the Comparable
> > implementation was moved up to the interface via default method, so I
> think
> > this is acceptable, via HBASE-23753. +1.
> >  * org.apache.hadoop.hbase.replication.ReplicationLoadSink -- Additional
> > constructor arguments added in HBASE-21406, -1.
> >  * org.apache.hadoop.hbase.replication.ReplicationLoadSource --
> Additional
> > constructor arguments added in HBASE-21505, -1.
> >  * org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> > constructor arguments added in HBASE-22648, -1.
> >  *
> >
> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad(...)
> > -- Method signature change on a protected method via HBASE-24221, -1.
> >  * org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
> > Method parameter removed via HBASE-21773, -1.
> >
> > Problems with Data Types, High Severity:
> >  * org.apache.hadoop.hbase.HConstants#HBASE_NON_USER_TABLE_DIRS -- Field
> > removed via HBASE-23055, -1.
> >  * org.apache.hadoop.hbase.HRegionInfo Removed super-interface
> > java.lang.Comparable -- same as HBASE-23753 above. Missing
> > interface moved to the super-interface, preserved. +1.
> >  * A number of interfaces seeing new methods. These interfaces look like
> > API we expect a client to consume, not implement. Book says under Client
> > API compatibility: "New APIs introduced in a patch version will only be
> > added in a source compatible way [1]: i.e. code that implements public
> APIs
> > will continue to compile." Strictly speaking, I think these are breaking
> > changes for a minor release, but since this is an interface we don't
> expect
> > clients to implement, only to consume, I'm -0.
> >  * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- class became
> > final, via HBASE-23956. We don't want clients (or anyone) to extend this
> > class. +1.
> >  * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- class
> > became final, via HBASE-21505. We don't want clients (or anyone) to
> extend
> > this class. +1.
> >  * org.apache.hadoop.hbase.mapreduce.RowCounter -- removed interface
> Tool,
> > via HBASE-21773. Now extends AbstractHBaseTool, which does implement
> > Tool. +1.
> >  * org.apache.hadoop.hbase.util.RegionMover -- 6 public fields made
> > private, via HBASE-24102. -1.
> >
> > Problems with Methods, High Severity:
> > * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- default
> > constructor made private, via HBASE-23956. -1.
> >
> > Problems with Methods, Medium Severity:
> >  * org.apache.hadoop.hbase.rest.filter.RestCsrfPreventionFilter.init(...)
> > -- removed declared thrown exception, via HBASE-23661. Clients don't

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Duo Zhang]

On NettyRpcClientConfigHelper I think it is fine. It is designed to be an
'util' class, so in HBASE-23956 we made it final and added a private
constructor. It only has static methods and is not expected to be extended
or instantiated by end users.

On ByteBufferUtils, it is IA.Private on master branch?

On the replication related classes, all the constructors are marked as
IA.Private, so I think they are all fine. Anyway, we should have a better
design, maybe something like the ClusterMetrics, where we introduce an
interface get the metrics.


Nick Dimiduk  于2020年6月19日周五 上午6:26写道：

> I've done some accounting of the source-incompatible changes. I'm not
> listing every item here, only the ones that I think might raise eyebrows or
> warrant further discussion. Here are my findings.
>
> I think these problems sink the RC. I plan to reopen the various tickets
> here and start a discussion with the authors for getting an addendum posted
> that addresses the problems. Before I do that, please speak up if you think
> anything here I've -1 are actually justified.
>
> Thanks,
> Nick
>
> Removed Methods:
>  * org.apache.hadoop.hbase.rest.client.{RemoteAdmin,RemoteHTable} -- these
> were dropped intentionally and with discussion via HBASE-24115, +1.
>  * org.apache.hadoop.hbase.util.ByteBufferUtils.findCommonPrefix (...) --
> looks like this method was refactored away as part of HBASE-22504. However,
> it is present in an IA.Public class, so it needs a deprecation cycle before
> removal, -1.
>  * org.apache.hadoop.hbase.HRegionInfo.compareTo -- the Comparable
> implementation was moved up to the interface via default method, so I think
> this is acceptable, via HBASE-23753. +1.
>  * org.apache.hadoop.hbase.replication.ReplicationLoadSink -- Additional
> constructor arguments added in HBASE-21406, -1.
>  * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- Additional
> constructor arguments added in HBASE-21505, -1.
>  * org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> constructor arguments added in HBASE-22648, -1.
>  *
> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad(...)
> -- Method signature change on a protected method via HBASE-24221, -1.
>  * org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
> Method parameter removed via HBASE-21773, -1.
>
> Problems with Data Types, High Severity:
>  * org.apache.hadoop.hbase.HConstants#HBASE_NON_USER_TABLE_DIRS -- Field
> removed via HBASE-23055, -1.
>  * org.apache.hadoop.hbase.HRegionInfo Removed super-interface
> java.lang.Comparable -- same as HBASE-23753 above. Missing
> interface moved to the super-interface, preserved. +1.
>  * A number of interfaces seeing new methods. These interfaces look like
> API we expect a client to consume, not implement. Book says under Client
> API compatibility: "New APIs introduced in a patch version will only be
> added in a source compatible way [1]: i.e. code that implements public APIs
> will continue to compile." Strictly speaking, I think these are breaking
> changes for a minor release, but since this is an interface we don't expect
> clients to implement, only to consume, I'm -0.
>  * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- class became
> final, via HBASE-23956. We don't want clients (or anyone) to extend this
> class. +1.
>  * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- class
> became final, via HBASE-21505. We don't want clients (or anyone) to extend
> this class. +1.
>  * org.apache.hadoop.hbase.mapreduce.RowCounter -- removed interface Tool,
> via HBASE-21773. Now extends AbstractHBaseTool, which does implement
> Tool. +1.
>  * org.apache.hadoop.hbase.util.RegionMover -- 6 public fields made
> private, via HBASE-24102. -1.
>
> Problems with Methods, High Severity:
> * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- default
> constructor made private, via HBASE-23956. -1.
>
> Problems with Methods, Medium Severity:
>  * org.apache.hadoop.hbase.rest.filter.RestCsrfPreventionFilter.init(...)
> -- removed declared thrown exception, via HBASE-23661. Clients don't extend
> this class, +1.
>  * org.apache.hadoop.hbase.client.RegionInfo.isEncodedRegionName(...) --
> removed thrown exception, via HBASE-23326. Clients don't extend this
> class, +1.
>  *
>
>
> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-2.3.0RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.3.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.3.0RC0:
> >
> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

I've done some accounting of the source-incompatible changes. I'm not
listing every item here, only the ones that I think might raise eyebrows or
warrant further discussion. Here are my findings.

I think these problems sink the RC. I plan to reopen the various tickets
here and start a discussion with the authors for getting an addendum posted
that addresses the problems. Before I do that, please speak up if you think
anything here I've -1 are actually justified.

Thanks,
Nick

Removed Methods:
 * org.apache.hadoop.hbase.rest.client.{RemoteAdmin,RemoteHTable} -- these
were dropped intentionally and with discussion via HBASE-24115, +1.
 * org.apache.hadoop.hbase.util.ByteBufferUtils.findCommonPrefix (...) --
looks like this method was refactored away as part of HBASE-22504. However,
it is present in an IA.Public class, so it needs a deprecation cycle before
removal, -1.
 * org.apache.hadoop.hbase.HRegionInfo.compareTo -- the Comparable
implementation was moved up to the interface via default method, so I think
this is acceptable, via HBASE-23753. +1.
 * org.apache.hadoop.hbase.replication.ReplicationLoadSink -- Additional
constructor arguments added in HBASE-21406, -1.
 * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- Additional
constructor arguments added in HBASE-21505, -1.
 * org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
constructor arguments added in HBASE-22648, -1.
 * org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad(...)
-- Method signature change on a protected method via HBASE-24221, -1.
 * org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
Method parameter removed via HBASE-21773, -1.

Problems with Data Types, High Severity:
 * org.apache.hadoop.hbase.HConstants#HBASE_NON_USER_TABLE_DIRS -- Field
removed via HBASE-23055, -1.
 * org.apache.hadoop.hbase.HRegionInfo Removed super-interface
java.lang.Comparable -- same as HBASE-23753 above. Missing
interface moved to the super-interface, preserved. +1.
 * A number of interfaces seeing new methods. These interfaces look like
API we expect a client to consume, not implement. Book says under Client
API compatibility: "New APIs introduced in a patch version will only be
added in a source compatible way [1]: i.e. code that implements public APIs
will continue to compile." Strictly speaking, I think these are breaking
changes for a minor release, but since this is an interface we don't expect
clients to implement, only to consume, I'm -0.
 * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- class became
final, via HBASE-23956. We don't want clients (or anyone) to extend this
class. +1.
 * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- class
became final, via HBASE-21505. We don't want clients (or anyone) to extend
this class. +1.
 * org.apache.hadoop.hbase.mapreduce.RowCounter -- removed interface Tool,
via HBASE-21773. Now extends AbstractHBaseTool, which does implement
Tool. +1.
 * org.apache.hadoop.hbase.util.RegionMover -- 6 public fields made
private, via HBASE-24102. -1.

Problems with Methods, High Severity:
* org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- default
constructor made private, via HBASE-23956. -1.

Problems with Methods, Medium Severity:
 * org.apache.hadoop.hbase.rest.filter.RestCsrfPreventionFilter.init(...)
-- removed declared thrown exception, via HBASE-23661. Clients don't extend
this class, +1.
 * org.apache.hadoop.hbase.client.RegionInfo.isEncodedRegionName(...) --
removed thrown exception, via HBASE-23326. Clients don't extend this
class, +1.
 *


On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:

> Please vote on this Apache hbase release candidate,
> hbase-2.3.0RC0
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.3.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.3.0RC0:
>
>   https://github.com/apache/hbase/tree/2.3.0RC0
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>
> Maven artifacts are available in a staging repository at:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1393/
>
> Artifacts were signed with the ndimi...@apache.org key which can be found
> in:
>
>   https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> To learn more about Apache hbase, please see
>
>   http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Duo,

Thank you for taking the time. I saw quite a bit of delta in the
compatibility report, which is concerning to me as well. Let me get back to
you here after spending some time with it. I'll also look more closely at
the size of the client tarball. This is a feature of our releases that I
have no experience with, so maybe someone here who's more familiar can take
a look?

Thanks,
Nick

On Wed, Jun 17, 2020 at 11:31 PM 张铎(Duo Zhang) 
wrote:

> +1(binding), thanks for your great work Nick.
>
> Checked sigs and sums: Matched
> Rat check: Passed
> Run all UTs: Passed. Excellent.
> Compatibility report: Fine, as said above.
> Started a local cluster and
> Checked the Web UI: Nothing strange.
> Then used the client bin and
> Run basic shell command: OK
> Run LTT with read/write 10k rows: Passed
>
> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
>
> Thanks.
>
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>
> > I'm still testing but let me post something about the compatibility
> report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001,
> by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and
> ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.org"
> >> > >> > gpg: Good signature from "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: aka "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: Note: This key has expired!
> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
> >> 8644
> >> > >> EEB6
> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
> >> 1C34
> >> > >> 89BD
> >> > >>
> >> > >>
> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> >> > wrote:
> >> > >>
> >> > >> > Please vote on this Apache hbase release candidate,
> >> > >> > hbase-2.3.0RC0
> >> > >> >
> >> > >> > The VOTE will remain open for at least 72 hours.
> >> > >> >
> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
> >> > >> > [ ] -1 Do not release this package because ...
> >> > >> >
> >> > >> > The tag to be voted on is 2.3.0RC0:
> >> > >> >
> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >> > >> >
> >> > >> > The release files, including signatures, digests, as well as
> >> > CHANGES.md
> >> > >> > and RELEASENOTES.md included in this RC can be found at:
> >> > >> >
> >> > >> >   https://dist.apache.org/repos/dist/dev

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Andrew,

Your test failure sounds like
https://issues.apache.org/jira/browse/HBASE-23970.

Thanks,
Nick

On Thu, Jun 18, 2020 at 1:15 PM Andrew Purtell  wrote:

> +1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_232): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_232): ok
>  - mvn clean install -DskipTests
> * Unit tests pass (1.8.0_232): failed
>  - mvn package -P runAllTests
>
> TestUsersOperationsWithSecureHadoop failed for me, but it's because of a
> local kerberos configuration issue.
>
> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-2.3.0RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.3.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.3.0RC0:
> >
> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1393/
> >
> > Artifacts were signed with the ndimi...@apache.org key which can be
> found
> > in:
> >
> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > To learn more about Apache hbase, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Viraj,

Do you happen to have the junit xml output from a failed run? You could
open a Flakey test ticket with the run log? I haven't looked at this test
specifically, but I've observed that these replication tests spin up
multiple miniclusters, which puts a huge strain on the system, and their
resource accounting doesn't always accommodate the slowdown of the system.
We could dig in some more.

Thanks,
Nick

On Thu, Jun 18, 2020 at 6:14 AM Viraj Jasani  wrote:

> +1
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_251): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_251): ok
>  - mvn clean install -DskipTests
> * Unit tests pass (1.8.0_251): failed
>  - mvn package -P runAllTests
>
> [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 29.212 s <<< FAILURE! - in
> org.apache.hadoop.hbase.replication.TestReplicationStatus
> [ERROR]
> org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink
> Time elapsed: 1.016 s  <<< FAILURE!
> java.lang.AssertionError: expected:<1592477704810> but was:<1592477719964>
> at
> org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink(TestReplicationStatus.java:134)
>
> After test results, I ran TestReplicationStatus separately on local and it
> passed, checked flaky and nightly dashboards, nightly is all good and flaky
> does't report TestReplicationStatus failures in available builds (at least
> for the past 3 days).
> The above failure indicates there are chances few edits are replicated
> before we even insert some data as part of the test.
>   //First checks if status of timestamp of last applied op is same as
> RS start, since no edits
>   //were replicated yet
>   assertEquals(loadSink.getTimestampStarted(),
> loadSink.getTimestampsOfLastAppliedOp());
>
> Anyways, locally this test looks all good. We can't run it in a loop
> within TestReplicationStatus as per the nature of the test, but all
> separate runs (mvn test
> -Dtest=org.apache.hadoop.hbase.replication.TestReplicationStatus) are
> passing.
>
>
>
> On 2020/06/18 06:31:04, 张铎(Duo Zhang)  wrote:
> > +1(binding), thanks for your great work Nick.
> >
> > Checked sigs and sums: Matched
> > Rat check: Passed
> > Run all UTs: Passed. Excellent.
> > Compatibility report: Fine, as said above.
> > Started a local cluster and
> > Checked the Web UI: Nothing strange.
> > Then used the client bin and
> > Run basic shell command: OK
> > Run LTT with read/write 10k rows: Passed
> >
> > My only concerns is that, the client-bin is even larger than the bin, 308
> > MB vs 260 MB. Is this expected? The main difference is the docs
> directory,
> > in bin it is 65 MB while in client-bin it is 681 MB.
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
> >
> > > I'm still testing but let me post something about the compatibility
> report
> > > first.
> > >
> > > There is an incompatible item about removing a method from the Admin
> > > interface, which should not happen for a minor release.
> > >
> > > package org.apache.hadoop.hbase.client
> > > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> > >
> > >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> > >
> > > Checked the release note and found out that it was done in
> HBASE-22001, by
> > > me...
> > > I just changed the return value from void to Future, so the
> > > compatibility report tells that the method which returns void has been
> > > removed.
> > >
> > > I think this is fine. We do not guarantee drop in replacement for a
> minor
> > > release, and it will not be a problem if users recompile their code.
> > >
> > > Thanks.
> > >
> > > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> > >
> > >> Thanks. I'm switching my vote to +1.
> > >>
> > >> - Signatures match (src/bin)
> > >> - Checksums match (src/bin)
> > >> - Compiled src from scratch
> > >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> > >> - Started a local mini cluster from compiled-src and bin artifacts
> and ran
> > >> some smoke tests - No issues
> > >> - Skimmed through the release notes.
> > >>
> > >> Thanks Nick for putting together such a high quality release,
> especially
> > >> all the work around docs/test flakes etc.
> > >>
> > >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> > >> wrote:
> > >>
> > >> > I have updated the KEYS file with revision 40069.
> > >> >
> > >> > I have also verified the content of the file on people.apache.org
> is
> > >> up to
> > >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> > >> >
> > >> > Thanks,
> > >> > Nick
> > >> >
> > >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> > >> wrote:
> > >> >
> > >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> > >> > > file and double-check id.a.o.
> > >> > >
> > >> > > Thanks for the reminder.
> > >> > >
> > >> > > On Tue, Jun 16, 2020 at 15:39 Bharat

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Andrew Purtell]

+1 (binding)

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_232): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_232): ok
 - mvn clean install -DskipTests
* Unit tests pass (1.8.0_232): failed
 - mvn package -P runAllTests

TestUsersOperationsWithSecureHadoop failed for me, but it's because of a
local kerberos configuration issue.

On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:

> Please vote on this Apache hbase release candidate,
> hbase-2.3.0RC0
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.3.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.3.0RC0:
>
>   https://github.com/apache/hbase/tree/2.3.0RC0
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>
> Maven artifacts are available in a staging repository at:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1393/
>
> Artifacts were signed with the ndimi...@apache.org key which can be found
> in:
>
>   https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> To learn more about Apache hbase, please see
>
>   http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Peter Somogyi]

+1 (binding)

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_252): ok
  - mvn clean apache-rat:check
* Built from source (1.8.0_252): ok
  - mvn clean install -DskipTests
* Unit tests pass (1.8.0_252): ok
  - mvn package -P runAllTests
* LTT 1M rows write: ok
* Simple shell operations: ok
* Logs: ok

nit: VersionInfo does not have SHA512 checksum. UI shows "From source with
checksum = (stdin)="

Thanks for the release Nick!

Peter


On Thu, Jun 18, 2020 at 3:15 PM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:

> +1 (binding)
>
>  * Signature: ok
>
>  * Checksum : ok
>
>  * Rat check (1.8.0_222): ok
>
>- mvn clean apache-rat:check
>
>  * Built from source (1.8.0_222): ok
>
> - mvn clean install -DskipTests
>
>  * Unit tests pass (1.8.0_222): ok
>
> - mvn package -P runSmallTests
>
>
> Deployed pseudo distributed on local FS:
>
> * Web UI: ok
>
> * CRUD: ok
>
> * ltt 10 rows: ok
>
> Em qui., 18 de jun. de 2020 às 07:31, 张铎(Duo Zhang)  >
> escreveu:
>
> > +1(binding), thanks for your great work Nick.
> >
> > Checked sigs and sums: Matched
> > Rat check: Passed
> > Run all UTs: Passed. Excellent.
> > Compatibility report: Fine, as said above.
> > Started a local cluster and
> > Checked the Web UI: Nothing strange.
> > Then used the client bin and
> > Run basic shell command: OK
> > Run LTT with read/write 10k rows: Passed
> >
> > My only concerns is that, the client-bin is even larger than the bin, 308
> > MB vs 260 MB. Is this expected? The main difference is the docs
> directory,
> > in bin it is 65 MB while in client-bin it is 681 MB.
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
> >
> > > I'm still testing but let me post something about the compatibility
> > report
> > > first.
> > >
> > > There is an incompatible item about removing a method from the Admin
> > > interface, which should not happen for a minor release.
> > >
> > > package org.apache.hadoop.hbase.client
> > > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> > >
> > >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> > >
> > > Checked the release note and found out that it was done in HBASE-22001,
> > by
> > > me...
> > > I just changed the return value from void to Future, so the
> > > compatibility report tells that the method which returns void has been
> > > removed.
> > >
> > > I think this is fine. We do not guarantee drop in replacement for a
> minor
> > > release, and it will not be a problem if users recompile their code.
> > >
> > > Thanks.
> > >
> > > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> > >
> > >> Thanks. I'm switching my vote to +1.
> > >>
> > >> - Signatures match (src/bin)
> > >> - Checksums match (src/bin)
> > >> - Compiled src from scratch
> > >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> > >> - Started a local mini cluster from compiled-src and bin artifacts and
> > ran
> > >> some smoke tests - No issues
> > >> - Skimmed through the release notes.
> > >>
> > >> Thanks Nick for putting together such a high quality release,
> especially
> > >> all the work around docs/test flakes etc.
> > >>
> > >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> > >> wrote:
> > >>
> > >> > I have updated the KEYS file with revision 40069.
> > >> >
> > >> > I have also verified the content of the file on people.apache.org
> is
> > >> up to
> > >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> > >> >
> > >> > Thanks,
> > >> > Nick
> > >> >
> > >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> > >> wrote:
> > >> >
> > >> > > Ah, could be. I did update the expiration date. Let me update the
> > KEYS
> > >> > > file and double-check id.a.o.
> > >> > >
> > >> > > Thanks for the reminder.
> > >> > >
> > >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> > >> bhara...@apache.org>
> > >> > > wrote:
> > >> > >
> > >> > >> -1 (binding)
> > >> > >>
> > >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> > FAQs
> > >> > >> ,
> "A
> > >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> > and
> > >> > >> doesn't complain about expired or revoked keys."
> > >> > >>
> > >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> > >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> > >> > >> > gpg:using RSA key
> > >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> > >> > >> > gpg:issuer "ndimi...@apache.org"
> > >> > >> > gpg: Good signature from "Nick Dimiduk "
> > >> > [expired]
> > >> > >> > gpg: aka "Nick Dimiduk "
> > >> > [expired]
> > >> > >> > gpg: Note: This key has expired!
> > >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36
> 33F1
> > >> 8644
> > >> > >> EEB6
> > >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90
> 3907
> > >>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Wellington Chevreuil]

+1 (binding)

 * Signature: ok

 * Checksum : ok

 * Rat check (1.8.0_222): ok

   - mvn clean apache-rat:check

 * Built from source (1.8.0_222): ok

- mvn clean install -DskipTests

 * Unit tests pass (1.8.0_222): ok

- mvn package -P runSmallTests


Deployed pseudo distributed on local FS:

* Web UI: ok

* CRUD: ok

* ltt 10 rows: ok

Em qui., 18 de jun. de 2020 às 07:31, 张铎(Duo Zhang) 
escreveu:

> +1(binding), thanks for your great work Nick.
>
> Checked sigs and sums: Matched
> Rat check: Passed
> Run all UTs: Passed. Excellent.
> Compatibility report: Fine, as said above.
> Started a local cluster and
> Checked the Web UI: Nothing strange.
> Then used the client bin and
> Run basic shell command: OK
> Run LTT with read/write 10k rows: Passed
>
> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
>
> Thanks.
>
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>
> > I'm still testing but let me post something about the compatibility
> report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001,
> by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and
> ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.org"
> >> > >> > gpg: Good signature from "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: aka "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: Note: This key has expired!
> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
> >> 8644
> >> > >> EEB6
> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
> >> 1C34
> >> > >> 89BD
> >> > >>
> >> > >>
> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> >> > wrote:
> >> > >>
> >> > >> > Please vote on this Apache hbase release candidate,
> >> > >> > hbase-2.3.0RC0
> >> > >> >
> >> > >> > The VOTE will remain open for at least 72 hours.
> >> > >> >
> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
> >> > >> > [ ] -1 Do not release this package because ...
> >> > >> >
> >> > >> > The tag to be voted on is 2.3.0RC0:
> >> > >> >
> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >> > >> >
> >> > >> > The release files, including signatures, digests, as well as
> >> > CHANGES.md
> >> > >> > and RELEASENOTES.md included in this RC can be found at:
> >> > >> >
> >> > >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >> > >> >
> >>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Viraj Jasani]

+1

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_251): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_251): ok
 - mvn clean install -DskipTests
* Unit tests pass (1.8.0_251): failed
 - mvn package -P runAllTests

[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 29.212 
s <<< FAILURE! - in org.apache.hadoop.hbase.replication.TestReplicationStatus
[ERROR] 
org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink
  Time elapsed: 1.016 s  <<< FAILURE!
java.lang.AssertionError: expected:<1592477704810> but was:<1592477719964>
at 
org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink(TestReplicationStatus.java:134)

After test results, I ran TestReplicationStatus separately on local and it 
passed, checked flaky and nightly dashboards, nightly is all good and flaky 
does't report TestReplicationStatus failures in available builds (at least for 
the past 3 days).
The above failure indicates there are chances few edits are replicated before 
we even insert some data as part of the test.
  //First checks if status of timestamp of last applied op is same as RS 
start, since no edits
  //were replicated yet
  assertEquals(loadSink.getTimestampStarted(), 
loadSink.getTimestampsOfLastAppliedOp());

Anyways, locally this test looks all good. We can't run it in a loop within 
TestReplicationStatus as per the nature of the test, but all separate runs (mvn 
test -Dtest=org.apache.hadoop.hbase.replication.TestReplicationStatus) are 
passing.



On 2020/06/18 06:31:04, 张铎(Duo Zhang)  wrote: 
> +1(binding), thanks for your great work Nick.
> 
> Checked sigs and sums: Matched
> Rat check: Passed
> Run all UTs: Passed. Excellent.
> Compatibility report: Fine, as said above.
> Started a local cluster and
> Checked the Web UI: Nothing strange.
> Then used the client bin and
> Run basic shell command: OK
> Run LTT with read/write 10k rows: Passed
> 
> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
> 
> Thanks.
> 
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
> 
> > I'm still testing but let me post something about the compatibility report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> > org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001, by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature, and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.or

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Duo Zhang]

+1(binding), thanks for your great work Nick.

Checked sigs and sums: Matched
Rat check: Passed
Run all UTs: Passed. Excellent.
Compatibility report: Fine, as said above.
Started a local cluster and
Checked the Web UI: Nothing strange.
Then used the client bin and
Run basic shell command: OK
Run LTT with read/write 10k rows: Passed

My only concerns is that, the client-bin is even larger than the bin, 308
MB vs 260 MB. Is this expected? The main difference is the docs directory,
in bin it is 65 MB while in client-bin it is 681 MB.

Thanks.

张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：

> I'm still testing but let me post something about the compatibility report
> first.
>
> There is an incompatible item about removing a method from the Admin
> interface, which should not happen for a minor release.
>
> package org.apache.hadoop.hbase.client
> Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
>
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
>
> Checked the release note and found out that it was done in HBASE-22001, by
> me...
> I just changed the return value from void to Future, so the
> compatibility report tells that the method which returns void has been
> removed.
>
> I think this is fine. We do not guarantee drop in replacement for a minor
> release, and it will not be a problem if users recompile their code.
>
> Thanks.
>
> Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
>
>> Thanks. I'm switching my vote to +1.
>>
>> - Signatures match (src/bin)
>> - Checksums match (src/bin)
>> - Compiled src from scratch
>> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
>> - Started a local mini cluster from compiled-src and bin artifacts and ran
>> some smoke tests - No issues
>> - Skimmed through the release notes.
>>
>> Thanks Nick for putting together such a high quality release, especially
>> all the work around docs/test flakes etc.
>>
>> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
>> wrote:
>>
>> > I have updated the KEYS file with revision 40069.
>> >
>> > I have also verified the content of the file on people.apache.org is
>> up to
>> > date, https://people.apache.org/keys/committer/ndimiduk.asc
>> >
>> > Thanks,
>> > Nick
>> >
>> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
>> wrote:
>> >
>> > > Ah, could be. I did update the expiration date. Let me update the KEYS
>> > > file and double-check id.a.o.
>> > >
>> > > Thanks for the reminder.
>> > >
>> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
>> bhara...@apache.org>
>> > > wrote:
>> > >
>> > >> -1 (binding)
>> > >>
>> > >> Looks like your key from the KEYS file has expired?  Per Apache FAQs
>> > >> , "A
>> > >> signature is valid, if gpg verifies the .asc as a good signature, and
>> > >> doesn't complain about expired or revoked keys."
>> > >>
>> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
>> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
>> > >> > gpg:using RSA key
>> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
>> > >> > gpg:issuer "ndimi...@apache.org"
>> > >> > gpg: Good signature from "Nick Dimiduk "
>> > [expired]
>> > >> > gpg: aka "Nick Dimiduk "
>> > [expired]
>> > >> > gpg: Note: This key has expired!
>> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
>> 8644
>> > >> EEB6
>> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
>> 1C34
>> > >> 89BD
>> > >>
>> > >>
>> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
>> > wrote:
>> > >>
>> > >> > Please vote on this Apache hbase release candidate,
>> > >> > hbase-2.3.0RC0
>> > >> >
>> > >> > The VOTE will remain open for at least 72 hours.
>> > >> >
>> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
>> > >> > [ ] -1 Do not release this package because ...
>> > >> >
>> > >> > The tag to be voted on is 2.3.0RC0:
>> > >> >
>> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
>> > >> >
>> > >> > The release files, including signatures, digests, as well as
>> > CHANGES.md
>> > >> > and RELEASENOTES.md included in this RC can be found at:
>> > >> >
>> > >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>> > >> >
>> > >> > Maven artifacts are available in a staging repository at:
>> > >> >
>> > >> >
>> > >>
>> https://repository.apache.org/content/repositories/orgapachehbase-1393/
>> > >> >
>> > >> > Artifacts were signed with the ndimi...@apache.org key which can
>> be
>> > >> found
>> > >> > in:
>> > >> >
>> > >> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
>> > >> >
>> > >> > To learn more about Apache hbase, please see
>> > >> >
>> > >> >   http://hbase.apache.org/
>> > >> >
>> > >> > Thanks,
>> > >> > Your HBase Release Manager
>> > >> >
>> > >>
>> > >
>> >
>>
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Duo Zhang]

I'm still testing but let me post something about the compatibility report
first.

There is an incompatible item about removing a method from the Admin
interface, which should not happen for a minor release.

package org.apache.hadoop.hbase.client
Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V

Checked the release note and found out that it was done in HBASE-22001, by
me...
I just changed the return value from void to Future, so the
compatibility report tells that the method which returns void has been
removed.

I think this is fine. We do not guarantee drop in replacement for a minor
release, and it will not be a problem if users recompile their code.

Thanks.

Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：

> Thanks. I'm switching my vote to +1.
>
> - Signatures match (src/bin)
> - Checksums match (src/bin)
> - Compiled src from scratch
> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> - Started a local mini cluster from compiled-src and bin artifacts and ran
> some smoke tests - No issues
> - Skimmed through the release notes.
>
> Thanks Nick for putting together such a high quality release, especially
> all the work around docs/test flakes etc.
>
> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk  wrote:
>
> > I have updated the KEYS file with revision 40069.
> >
> > I have also verified the content of the file on people.apache.org is up
> to
> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >
> > Thanks,
> > Nick
> >
> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> wrote:
> >
> > > Ah, could be. I did update the expiration date. Let me update the KEYS
> > > file and double-check id.a.o.
> > >
> > > Thanks for the reminder.
> > >
> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> bhara...@apache.org>
> > > wrote:
> > >
> > >> -1 (binding)
> > >>
> > >> Looks like your key from the KEYS file has expired?  Per Apache FAQs
> > >> , "A
> > >> signature is valid, if gpg verifies the .asc as a good signature, and
> > >> doesn't complain about expired or revoked keys."
> > >>
> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> > >> > gpg:using RSA key
> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> > >> > gpg:issuer "ndimi...@apache.org"
> > >> > gpg: Good signature from "Nick Dimiduk "
> > [expired]
> > >> > gpg: aka "Nick Dimiduk "
> > [expired]
> > >> > gpg: Note: This key has expired!
> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
> 8644
> > >> EEB6
> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
> 1C34
> > >> 89BD
> > >>
> > >>
> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> > wrote:
> > >>
> > >> > Please vote on this Apache hbase release candidate,
> > >> > hbase-2.3.0RC0
> > >> >
> > >> > The VOTE will remain open for at least 72 hours.
> > >> >
> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
> > >> > [ ] -1 Do not release this package because ...
> > >> >
> > >> > The tag to be voted on is 2.3.0RC0:
> > >> >
> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> > >> >
> > >> > The release files, including signatures, digests, as well as
> > CHANGES.md
> > >> > and RELEASENOTES.md included in this RC can be found at:
> > >> >
> > >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> > >> >
> > >> > Maven artifacts are available in a staging repository at:
> > >> >
> > >> >
> > >>
> https://repository.apache.org/content/repositories/orgapachehbase-1393/
> > >> >
> > >> > Artifacts were signed with the ndimi...@apache.org key which can be
> > >> found
> > >> > in:
> > >> >
> > >> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> > >> >
> > >> > To learn more about Apache hbase, please see
> > >> >
> > >> >   http://hbase.apache.org/
> > >> >
> > >> > Thanks,
> > >> > Your HBase Release Manager
> > >> >
> > >>
> > >
> >
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Bharath Vissapragada]

Thanks. I'm switching my vote to +1.

- Signatures match (src/bin)
- Checksums match (src/bin)
- Compiled src from scratch
- Ran unit-tests from src (-PrunSmallTests, Java8). No failures
- Started a local mini cluster from compiled-src and bin artifacts and ran
some smoke tests - No issues
- Skimmed through the release notes.

Thanks Nick for putting together such a high quality release, especially
all the work around docs/test flakes etc.

On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk  wrote:

> I have updated the KEYS file with revision 40069.
>
> I have also verified the content of the file on people.apache.org is up to
> date, https://people.apache.org/keys/committer/ndimiduk.asc
>
> Thanks,
> Nick
>
> On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk  wrote:
>
> > Ah, could be. I did update the expiration date. Let me update the KEYS
> > file and double-check id.a.o.
> >
> > Thanks for the reminder.
> >
> > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada 
> > wrote:
> >
> >> -1 (binding)
> >>
> >> Looks like your key from the KEYS file has expired?  Per Apache FAQs
> >> , "A
> >> signature is valid, if gpg verifies the .asc as a good signature, and
> >> doesn't complain about expired or revoked keys."
> >>
> >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > gpg:using RSA key
> >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > gpg:issuer "ndimi...@apache.org"
> >> > gpg: Good signature from "Nick Dimiduk "
> [expired]
> >> > gpg: aka "Nick Dimiduk "
> [expired]
> >> > gpg: Note: This key has expired!
> >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1 8644
> >> EEB6
> >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907 1C34
> >> 89BD
> >>
> >>
> >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> wrote:
> >>
> >> > Please vote on this Apache hbase release candidate,
> >> > hbase-2.3.0RC0
> >> >
> >> > The VOTE will remain open for at least 72 hours.
> >> >
> >> > [ ] +1 Release this package as Apache hbase 2.3.0
> >> > [ ] -1 Do not release this package because ...
> >> >
> >> > The tag to be voted on is 2.3.0RC0:
> >> >
> >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >> >
> >> > The release files, including signatures, digests, as well as
> CHANGES.md
> >> > and RELEASENOTES.md included in this RC can be found at:
> >> >
> >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >> >
> >> > Maven artifacts are available in a staging repository at:
> >> >
> >> >
> >> https://repository.apache.org/content/repositories/orgapachehbase-1393/
> >> >
> >> > Artifacts were signed with the ndimi...@apache.org key which can be
> >> found
> >> > in:
> >> >
> >> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> >> >
> >> > To learn more about Apache hbase, please see
> >> >
> >> >   http://hbase.apache.org/
> >> >
> >> > Thanks,
> >> > Your HBase Release Manager
> >> >
> >>
> >
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

I have updated the KEYS file with revision 40069.

I have also verified the content of the file on people.apache.org is up to
date, https://people.apache.org/keys/committer/ndimiduk.asc

Thanks,
Nick

On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk  wrote:

> Ah, could be. I did update the expiration date. Let me update the KEYS
> file and double-check id.a.o.
>
> Thanks for the reminder.
>
> On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada 
> wrote:
>
>> -1 (binding)
>>
>> Looks like your key from the KEYS file has expired?  Per Apache FAQs
>> , "A
>> signature is valid, if gpg verifies the .asc as a good signature, and
>> doesn't complain about expired or revoked keys."
>>
>> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
>> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
>> > gpg:using RSA key
>> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
>> > gpg:issuer "ndimi...@apache.org"
>> > gpg: Good signature from "Nick Dimiduk " [expired]
>> > gpg: aka "Nick Dimiduk " [expired]
>> > gpg: Note: This key has expired!
>> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1 8644
>> EEB6
>> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907 1C34
>> 89BD
>>
>>
>> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:
>>
>> > Please vote on this Apache hbase release candidate,
>> > hbase-2.3.0RC0
>> >
>> > The VOTE will remain open for at least 72 hours.
>> >
>> > [ ] +1 Release this package as Apache hbase 2.3.0
>> > [ ] -1 Do not release this package because ...
>> >
>> > The tag to be voted on is 2.3.0RC0:
>> >
>> >   https://github.com/apache/hbase/tree/2.3.0RC0
>> >
>> > The release files, including signatures, digests, as well as CHANGES.md
>> > and RELEASENOTES.md included in this RC can be found at:
>> >
>> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>> >
>> > Maven artifacts are available in a staging repository at:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapachehbase-1393/
>> >
>> > Artifacts were signed with the ndimi...@apache.org key which can be
>> found
>> > in:
>> >
>> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
>> >
>> > To learn more about Apache hbase, please see
>> >
>> >   http://hbase.apache.org/
>> >
>> > Thanks,
>> > Your HBase Release Manager
>> >
>>
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Ah, could be. I did update the expiration date. Let me update the KEYS file
and double-check id.a.o.

Thanks for the reminder.

On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada 
wrote:

> -1 (binding)
>
> Looks like your key from the KEYS file has expired?  Per Apache FAQs
> , "A
> signature is valid, if gpg verifies the .asc as a good signature, and
> doesn't complain about expired or revoked keys."
>
> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> > gpg:using RSA key
> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> > gpg:issuer "ndimi...@apache.org"
> > gpg: Good signature from "Nick Dimiduk " [expired]
> > gpg: aka "Nick Dimiduk " [expired]
> > gpg: Note: This key has expired!
> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1 8644
> EEB6
> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907 1C34
> 89BD
>
>
> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-2.3.0RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.3.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.3.0RC0:
> >
> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1393/
> >
> > Artifacts were signed with the ndimi...@apache.org key which can be
> found
> > in:
> >
> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > To learn more about Apache hbase, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Bharath Vissapragada]

-1 (binding)

Looks like your key from the KEYS file has expired?  Per Apache FAQs
, "A
signature is valid, if gpg verifies the .asc as a good signature, and
doesn't complain about expired or revoked keys."

gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> gpg:using RSA key 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> gpg:issuer "ndimi...@apache.org"
> gpg: Good signature from "Nick Dimiduk " [expired]
> gpg: aka "Nick Dimiduk " [expired]
> gpg: Note: This key has expired!
> Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1 8644 EEB6
>  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907 1C34 89BD


On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:

> Please vote on this Apache hbase release candidate,
> hbase-2.3.0RC0
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.3.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.3.0RC0:
>
>   https://github.com/apache/hbase/tree/2.3.0RC0
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>
> Maven artifacts are available in a staging repository at:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1393/
>
> Artifacts were signed with the ndimi...@apache.org key which can be found
> in:
>
>   https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> To learn more about Apache hbase, please see
>
>   http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>