[
https://issues.apache.org/jira/browse/HBASE-23055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-23055.
---
Resolution: Fixed
Pushed addendum on branch-2.3+
> Alter hbase:meta
>
>
>
[
https://issues.apache.org/jira/browse/HBASE-24605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guangxu Cheng resolved HBASE-24605.
---
Fix Version/s: 2.2.6
2.4.0
2.3.1
Abhishek Singh Chouhan created HBASE-24618:
--
Summary: Backport HBASE-21204 to branch-1
Key: HBASE-24618
URL: https://issues.apache.org/jira/browse/HBASE-24618
Project: HBase
Issue
Matthew Foley created HBASE-24617:
-
Summary: Enable injecting build start time value as part of build
Key: HBASE-24617
URL: https://issues.apache.org/jira/browse/HBASE-24617
Project: HBase
Sorry, I should've been clearer. It's the former. My point is, any method
tagged with @VisibleForTesting is only intended for testing purposes and
should _not_ be considered public, its visibility scope is wider than
necessary only because it was needed by some test method. That's how I'd
Michael Stack created HBASE-24616:
-
Summary: Remove BoundedRecoveredHFilesOutputSink dependency on a
TableDescriptor
Key: HBASE-24616
URL: https://issues.apache.org/jira/browse/HBASE-24616
Project:
[
https://issues.apache.org/jira/browse/HBASE-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved HBASE-15161.
--
Fix Version/s: 2.3.0
3.0.0-alpha-1
Resolution: Fixed
> Umbrella:
On Mon, Jun 22, 2020 at 3:45 PM Bharath Vissapragada
wrote:
> I share the same opinion. Infact hadoop (from which our annotations are
> derived I believe), talks about this, "Also, certain APIs are annotated as
> @VisibleForTesting (from com.google.common .annotations.VisibleForTesting)
> -
I share the same opinion. Infact hadoop (from which our annotations are
derived I believe), talks about this, "Also, certain APIs are annotated as
@VisibleForTesting (from com.google.common .annotations.VisibleForTesting)
- these are meant to be used strictly for unit tests and should be treated
Rushabh Shah created HBASE-24615:
Summary: MutableRangeHistogram#updateSnapshotRangeMetrics doesn't
calculate the distribution for last bucket.
Key: HBASE-24615
URL:
+1 to remove master-slave terminology and favor the proposals that Andrew
mentions. This is the right thing to do as community.
Thanks,
Esteban.
--
Cloudera, Inc.
On Mon, Jun 22, 2020 at 4:28 PM Zach York
wrote:
> While reading the definitions, I think it is pretty clear that the
>
[
https://issues.apache.org/jira/browse/HBASE-24144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened HBASE-24144:
--
Reopening so as to include HBASE-24231.
> Update docs from master
> ---
>
>
Let us look at what *slave* mean
According to the merriam-webster
https://www.merriam-webster.com/dictionary/slave
Definition of *slave*
(Entry 1 of 4)
1: a person held in servitude as the chattel of another
2: one that is completely subservient to a dominating influence
3: a device (such as
While reading the definitions, I think it is pretty clear that the
definition HBase is intending is somewhere under the #2 definition link.
HMaster is not a teacher (which implies learning on the "student" side),
but rather orders the RS to do a task.
I think master in this context is still worth
Regarding "slave", it is a stretch to point to an esoteric technical
definition and ask someone to pretend like all the other pejorative
meanings relating to power relationship are somehow not meaningful. If we
were to be accused of "turning a blind eye", that charge would stick, in my
opinion.
In observing something like voting happening on this thread to express
alignment or not, it might be helpful to first, come up with a list of
terms to change (if any), and then propose replacements, individually. So
far we might break this apart into four proposals:
1. Replace "master"/"hmaster"
For most of the proposals (slave -> worker, blacklist -> denylist,
whitelist-> allowlist), I'm +1 (nonbinding). Denylist and acceptlist even
have the advantage of being clearer than the terms they're replacing.
However, I'm not convinced about changing "master" to "coordinator", or
something
In mitigation, we should only do the revision if the community feels:
1. There is a need to revise historical context
2. We by virtue of accepting changes will make a better team
3. It will have little or no impact on the current functionality
4. Given that most products in
+1 to renaming.
Rushabh Shah
- Software Engineering SMTS | Salesforce
-
- Mobile: 213 422 9052
On Mon, Jun 22, 2020 at 1:18 PM Josh Elser wrote:
> +1
>
> On 6/22/20 4:03 PM, Sean Busbey wrote:
> > We should change our use of these terms. We can be equally or more clear
> in
> >
+1
On 6/22/20 4:03 PM, Sean Busbey wrote:
We should change our use of these terms. We can be equally or more clear in
what we are trying to convey where they are present.
That they have been used historically is only useful if the advantage we
gain from using them through that shared context
>From my perspective, we gain nothing as a project or as a community be
willfully retaining use of language that is well understood to be
problematic or hurtful, even if that terminology has precedent in the
technology domain. On the contrary, we have much to gain by encouraging
contributions from
We should change our use of these terms. We can be equally or more clear in
what we are trying to convey where they are present.
That they have been used historically is only useful if the advantage we
gain from using them through that shared context outweighs the potential
friction they add.
Hi,
Thank you for the proposals.
I am afraid I have to agree to differ. The term master and slave (commonly
used in Big data tools (not confined to HBase only) is BAU and historical)
and bears no resemblance to anything recent.
Additionally, both whitelist and blacklist simply refer to a
Thank you Mich.
Hopefully it is clear that there is no community consensus yet, and all voices
are welcome on the topic.
> On Jun 22, 2020, at 12:15 PM, Mich Talebzadeh
> wrote:
>
> Hi,
>
> Thank you for the proposals.
>
> I am afraid I have to agree to differ. The term master and slave
In response to renewed attention at the Foundation toward addressing
culturally problematic language and terms often used in technical
documentation and discussion, several projects have begun discussions, or
made proposals, or started work along these lines.
The HBase PMC began its own
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:
>
[
https://issues.apache.org/jira/browse/HBASE-24102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-24102.
--
Resolution: Fixed
Addendum is committed to master, branch-2, 2.3, 2.2, 2.1.
> RegionMover
Yeah I would say no as well. We should make clear on our dev guide that you
also should be marking those things with an Interface Audience marking if
you don't intend them to be at the downstream API visibility of the parent
class.
(IIRC we also use VisibleForTesting in IA.Private classes to
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.
[
https://issues.apache.org/jira/browse/HBASE-24102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened HBASE-24102:
--
This issue removed visibility of 6 fields on {{o.a.h.h.util.RegionMover}}
without a deprecation
[
https://issues.apache.org/jira/browse/HBASE-23055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened HBASE-23055:
--
This issue drops {{HConstants#HBASE_NON_USER_TABLE_DIRS}} without a deprecation
cycle.
[
https://issues.apache.org/jira/browse/HBASE-21773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened HBASE-21773:
--
This issue changes the method signature of
o.a.h.h.mapreduce.RowCounter#createSubmittableJob in
Hello,
This came up over on the 2.3.0RC0 thread, so let's open it for proper
discussion. In that context, we observe method signature changes to a
method marked with the Guava VisibleForTesting annotation. The method is a
protected method on a IA.Public class. There is no method-level IA
[
https://issues.apache.org/jira/browse/HBASE-22504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened HBASE-22504:
--
>From the 2.3.0RC0, looks like this change introduced a breach of our
>compatibility guidelines.
> 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
Nick Dimiduk created HBASE-24614:
Summary: o.a.h.h.tool.LoadIncrementalHFiles deprecation comment
does not span an entire release
Key: HBASE-24614
URL: https://issues.apache.org/jira/browse/HBASE-24614
Aleksandr created HBASE-24613:
-
Summary: Doesn't work SplitPolicy attributs for table
Key: HBASE-24613
URL: https://issues.apache.org/jira/browse/HBASE-24613
Project: HBase
Issue Type: Bug
Mark Robert Miller created HBASE-24612:
--
Summary: Consider allowing a separate EventLoopGroup for accepting
new connections.
Key: HBASE-24612
URL: https://issues.apache.org/jira/browse/HBASE-24612
[
https://issues.apache.org/jira/browse/HBASE-24604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-24604.
--
Fix Version/s: 3.0.0-alpha-1
Hadoop Flags: Reviewed
Resolution: Fixed
Merged PR
[
https://issues.apache.org/jira/browse/HBASE-24611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-24611.
--
Resolution: Fixed
Applied addendum to branch-2 and branch-2.3.
> Bring back old constructor
[
https://issues.apache.org/jira/browse/HBASE-24611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani reopened HBASE-24611:
--
> Bring back old constructor of SnapshotDescription
>
41 matches
Mail list logo
