+1, can only see benefits of using GitHub PRs over attached patches.
On Fri, 21 Feb 2020, 21:33 Andrew Purtell, wrote:
> +1 to the idea, having one contribution workflow instead of two is 50% less
> confusing (or 100% depending how you count it).
>
> > applying a patch for local evaluation is m
The bot is for lots of projects, not only HBase, so we can not shut it down.
My concern is that, do we really need to shut it down completely? The pre
commit job is still fine I think? So just leave it as is? And when
sometimes it is broken and needs a lot of effort to maintain, then we can
shut i
The issue aims to make rs group the first class citizen in HBase, where the
feature can be enabled through a simple flag, not a complicated
coprocessor, and also we can manage it through the Admin interface, while
in the old time the only public way is to through the shell command, as the
coprocess
There's a dedicated precommit job just for the hbase main repo. We can shut
it down without impacting other projects or even other hbase repos. There's
already debt on that job; Nick has been starting to pay it down and I'd
imagine that's how we got to this thread about just turning it off. For
exa
Bo Cui created HBASE-23884:
--
Summary: list_rsgroups didn't get the correct result
Key: HBASE-23884
URL: https://issues.apache.org/jira/browse/HBASE-23884
Project: HBase
Issue Type: Bug
Com
Michael Stack created HBASE-23885:
-
Summary: [Flakey Test] TestReplicationStatus
Key: HBASE-23885
URL: https://issues.apache.org/jira/browse/HBASE-23885
Project: HBase
Issue Type: Bug
Bo Cui created HBASE-23886:
--
Summary: FileSystemUtilizationChore reduces unnecessary regions
Key: HBASE-23886
URL: https://issues.apache.org/jira/browse/HBASE-23886
Project: HBase
Issue Type: Improv
