Looks good to me.
S
On Thu, May 9, 2019 at 7:02 PM Sean Busbey wrote:
> Hi folks!
>
> just a heads up that a few of us are planning to move a class out of
> the public API without a deprecation cycle.
>
> From the planned release note:
>
> > The class LossyCounting was unintentionally marked
Personally when available I spent more time in branch-1 release voting than
branch-2 since I think branch-1 is still the stable pointer, also the main
usage in production. For the same reason I'm more cautious to give a +1 for
branch-1. For me a -1 is not a veto but something noticeable, while I
[
https://issues.apache.org/jira/browse/HBASE-18373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki resolved HBASE-18373.
--
Resolution: Not A Problem
> fstat unimplemented error on Rasbian Jessie
>
Hi folks!
just a heads up that a few of us are planning to move a class out of
the public API without a deprecation cycle.
>From the planned release note:
> The class LossyCounting was unintentionally marked Public but was never
> intended to be part of our public API. This oversight has been
> In that regard I think we should be easier on newcomers. Old timers
should know better and follow up with jiras.
This is a fair point.
I would say anyone should feel free to raise a question in the vote thread,
or file a JIRA and mention it. I can only speak for myself but questions or
I would +1 a backport of HBASE-19735 to branch-1 if someone wanted to
contribute it. It looks like maven should just do the right thing and there
is no extra work for the RM; simply another artifact gets published. We can
include this in 1.5.0 and later?
On Thu, May 9, 2019 at 5:49 PM Artem
Andrew, I can only imagine how hard it is to be an RM, it takes me hours to
review a release let alone roll one. With so many RCs for each branch, it's
hard to focus on which branch to target and like you said volunteer time is
expensive. Sometimes for new contributors it is uncertain whether the
We have a self supporting cohort of RMs, voters, and contributors for
branch-2 but not branch-1. I agree this is misaligned with the user centric
focus if we define 'user' as someone using a version that has the stable
pointer pointing to it. (smile)
If anything this thread is a plea from me to
That would be interesting given that in our experience prototyping on
branch-2.1, it is really not ready for production usage.
We fixed many bugs (mostly in the assignment; most either committed or PA in
JIRA, internally we run with all of those) and keep finding new critical ones
all the time
[
https://issues.apache.org/jira/browse/HBASE-22389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zach York resolved HBASE-22389.
---
Resolution: Fixed
Fix Version/s: 1.4.11
1.5.0
> Revert HBASE-19275
Xu Cang created HBASE-22391:
---
Summary: Fix flaky tests from TestFromClientSide
Key: HBASE-22391
URL: https://issues.apache.org/jira/browse/HBASE-22391
Project: HBase
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/HBASE-21800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-21800.
Resolution: Fixed
> RegionServer aborted due to NPE from MetaTableMetrics coprocessor
>
Thank you, I will follow up on those issues.
On Thu, May 9, 2019 at 1:38 PM Peter Somogyi wrote:
> Sorry I didn't mention it here, but when voting I reopened HBASE-21800 and
> HBASE-21991. These introduced changes to LossyCounting, which is currently
> IA.Public. I asked the contributor on JIRA
Sorry I didn't mention it here, but when voting I reopened HBASE-21800 and
HBASE-21991. These introduced changes to LossyCounting, which is currently
IA.Public. I asked the contributor on JIRA to provide a patch for the
incompatibility. Maybe this class shouldn't be IA.Public; I'd be fine with
Zach York created HBASE-22390:
-
Summary: backport HBASE-22190 to branch-1
Key: HBASE-22390
URL: https://issues.apache.org/jira/browse/HBASE-22390
Project: HBase
Issue Type: Bug
Affects
[
https://issues.apache.org/jira/browse/HBASE-22330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Singh Chouhan reopened HBASE-22330:
Hardening the test
> Backport HBASE-20724 (Sometimes some compacted
Zach York created HBASE-22389:
-
Summary: Revert HBASE-19275 TestSnapshotFileCache never worked
properly on branch-1
Key: HBASE-22389
URL: https://issues.apache.org/jira/browse/HBASE-22389
Project: HBase
As was pointed out on another thread it's my personal take to be treating
-1 votes as vetos, so as point of order this is not a veto. Apologies for
causing any confusion there. As the remainder of my response, I think the
call to courtesy in those words should stand and are submitted for your
Yes, I am already using that phrasing, because it is very difficult to get
voting interest in any 1.x release candidate. See my other response in this
regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large
aspect of why I find it so frustrating to try and make progress with these
Also, it is my observation that we are really only seeing difficulty
attracting votes when RMs offer a 1.x release candidate. Maybe this implies
the entire branch-1 forest should EOL. This will strand major users still
on 1.x but it appears to be the consensus will of the community, if you
Personally I don't think we have enough community release voting to
support having closing dates on votes. This was definitely the case on
1.2 releases. IIRC it was also true fo the last 1.3 release.
I think you're already using the "I would like to close this around
XXX" phrasing, but just in
Sure I will concede treating -1s as vetos is a contributing factor, but I
think this is just a nod to reality. We have a hard enough time attracting
votes on a candidate as it is. When a -1 is cast, maybe I am insufficiently
optimistic, but I strongly suspect we won't get enough +1s to overcome
-1s on a release aren't a veto unless the RM treats them that way.
Granted, given our current rate of votes they are very hard to
overcome. I'm painfully aware of the time that goes into putting up an
RC, and I don't think you should continue handling -1s as vetos.
As a voter on RCs I try very
Something like that would be an improvement. I think my frustration stems
from a sense the burden isn't equitably shared. It also relates to what I
do as a RM which isn't policy per se. First, I run the unit suite several
times in a loop. This is scripted, but it takes time to complete and review
Artem Ervits created HBASE-22388:
Summary: Document new completebulkload invocation in 3.x when
LoadIncrementalHFiles is removed
Key: HBASE-22388
URL: https://issues.apache.org/jira/browse/HBASE-22388
should -1 only apply with a valid critical Jira in hand?
On Thu, May 9, 2019 at 12:41 PM Andrew Purtell
wrote:
> .. a code base to the RM role. I don't believe vetos for RCs for flaky
> tests should be considered valid reason to vote -1. I think we may be
> erring toward excessively maximal
.. a code base to the RM role. I don't believe vetos for RCs for flaky
tests should be considered valid reason to vote -1. I think we may be
erring toward excessively maximal interpretation of compatibility
guidelines in some cases. At any rate, where does the responsibility lie
for fixing the
Are you referring to the changes I called out in HBASE-22215 or something else?
If HBASE-22215 please do us the courtesy of reopening it with your objection,
because the change was given due consideration there already.
Additive changes to LP classes are allowed, I believe, but you will need
/cc private@
I believe you are pushing your collective burden as a group of committers
sharing responsiblity to
On Thu, May 9, 2019 at 9:33 AM Andrew Purtell
wrote:
> My experience with the last four RC attempts I have made has been just a
> constant stream of vetos for flaky tests which I
My experience with the last four RC attempts I have made has been just a
constant stream of vetos for flaky tests which I can't reproduce (at least not
with the usual 10 iterations of the suite) and possibly pedantic compatability
report interpretations with no patches to help and in some cases
Hello Team,
ZooKeeper recently added a feature to enable compression for values stored
in ZNodes when the nodes are persisted to disk. Obviously this feature is
less interesting if the data written into the ZNodes is already compressed.
https://issues.apache.org/jira/browse/ZOOKEEPER-3179
With
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-22149.
-
Resolution: Fixed
Fix Version/s: hbase-filesystem-1.0.0-alpha1
Release Note:
Congratulations Jan!
On Thu, May 9, 2019 at 12:07 PM Lars Francke wrote:
> Congratulations Jan and especially thank you for your work on the
> deprecations
>
> On Wed, May 8, 2019 at 11:37 PM Sean Busbey wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Jan
> >
[
https://issues.apache.org/jira/browse/HBASE-22358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel resolved HBASE-22358.
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 1.4.11
Congratulations Jan and especially thank you for your work on the
deprecations
On Wed, May 8, 2019 at 11:37 PM Sean Busbey wrote:
> On behalf of the Apache HBase PMC I am pleased to announce that Jan
> Hentschel has accepted our invitation to become a PMC member on the
> HBase project. We
[
https://issues.apache.org/jira/browse/HBASE-21800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi reopened HBASE-21800:
---
> RegionServer aborted due to NPE from MetaTableMetrics coprocessor
>
[
https://issues.apache.org/jira/browse/HBASE-21991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi reopened HBASE-21991:
---
> Fix MetaMetrics issues - [Race condition, Faulty remove logic], few
> improvements
>
-1
Compatibility report shows removed methods and changed constructor
signature for a IA.Public interface. There are also a couple of changes for
IA.LP classes.
Also checked:
Checksum, signature OK
Rat check OK
Unit tests OK
Simple shell commands OK
LTT 1M rows OK
Master, RS UI OK
On Sat, May
Zheng Hu created HBASE-22387:
Summary: Evaluate the get/scan performance after reading HFile
block into offheap directly
Key: HBASE-22387
URL: https://issues.apache.org/jira/browse/HBASE-22387
Project:
39 matches
Mail list logo
