more discussion. There is no consensus, yet, on what
> > > > replacement term is best. Personally, I can accept Zheng's recent
> > > > suggestion of "controller". I can see how syllable count matters.
> > > >
> > > > I don't mean this summary to close the conversation. It is only a
>
>
> > > I don't mean this summary to close the conversation. It is only a
> > > checkpoint.
> > >
> > > If anyone reading this has an opinion they do not wish to express
> > > publically, you are welcome to write to priv...@hbase.apache.org to
> > state
> > >
ding this has an opinion they do not wish to express
> > publically, you are welcome to write to priv...@hbase.apache.org to
> state
> > your opinion and the PMC will of course respectfully listen to it.
> >
> >
> >
> > On Thu, Jun 25, 2020 at 7:47 PM zhen
>
>
>
> On Thu, Jun 25, 2020 at 7:47 PM zheng wang <18031...@qq.com> wrote:
>
> > I like the controller.
> >
> >
> > Coordinator is a bit long for me to write and speak.
> > Manager and Admin is used somewhere yet in HBase.
> >
> >
>
speak.
> Manager and Admin is used somewhere yet in HBase.
>
>
>
>
> ------ 原始邮件 ------
> 发件人: "Andrew Purtell" 发送时间: 2020年6月26日(星期五) 上午9:08
> 收件人: "Hbase-User" 抄送: "dev" 主题: Re: [DISCUSS] Removing problematic
t; > > > > > >
> > > > > > > It seems to me we have, broadly speaking, consensus around
> making
> > > > > *some*
> > > > > > > > changes. I haven't seen a strong push for "break everything
> in
> > > th
t; the
> > > > name
> > > > > > of
> > > > > > > expediency" (I would personally be fine with this). So barring
> > > > > additional
> > > > > > > discussion that favors breaking changes, current approa
> > additional
> > > > > > discussion that favors breaking changes, current approaches
> should
> > > > > comport
> > > > > > with our existing project compatibility goals.
> > > > > >
> > > > > > M
g the work of a PR we
> can
> > > > look
> > > > > at for one of these?
> > > > >
> > > > > If folks would prefer we e.g. just say "we should break whatever we
> > > need
> > > > to
> > > > > in 3.0.0
gt; examples? If anyone is currently up for doing the work of a PR we
> can
> > > > look
> > > > > at for one of these?
> > > > >
> > > > > If folks would prefer we e.g. just say "we should break whatever we
> > > need
>
> in 3.0.0 to make this happen" then it would be good to speak up.
> > > Otherwise
> > > > likely we would be done with needed changes circa hbase 4, probably
> > late
> > > > 2021 or 2022.
> > > >
> > > >
> > > > On
whatever we
> need
> > to
> > > in 3.0.0 to make this happen" then it would be good to speak up.
> > Otherwise
> > > likely we would be done with needed changes circa hbase 4, probably
> late
> > > 2021 or 2022.
> > >
> > >
> > > On Tue
circa hbase 4, probably late
> > 2021 or 2022.
> >
> >
> > On Tue, Jun 23, 2020, 03:03 zheng wang <18031...@qq.com> wrote:
> >
> > > IMO, master is ok if not used with slave together.
> > >
> > >
> > > -1/+1/+1/+1
> > >
> >
> >
> > ------ 原始邮件 ------
> > 发件人: "Andrew Purtell" > 发送时间: 2020年6月23日(星期二) 凌晨5:24
> > 收件人: "Hbase-User" > 抄送: "dev" > 主题: Re: [DISCUSS] Removing problematic terms from our project
> >
&
ng wang <18031...@qq.com> wrote:
> >
> > > IMO, master is ok if not used with slave together.
> > >
> > >
> > > -1/+1/+1/+1
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "Andrew Purte
lave together.
> >
> >
> > -1/+1/+1/+1
> >
> >
> > ------ 原始邮件 ----------
> > 发件人: "Andrew Purtell" > 发送时间: 2020年6月23日(星期二) 凌晨5:24
> > 收件人: "Hbase-User" > 抄送: "dev" > 主题: Re: [DISCUSS] Removing pro
原始邮件 --
> 发件人: "Andrew Purtell" 发送时间: 2020年6月23日(星期二) 凌晨5:24
> 收件人: "Hbase-User" 抄送: "dev" 主题: Re: [DISCUSS] Removing problematic terms from our project
>
>
>
> In observing something like voting happening on this thread to express
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" w
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 t
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 simil
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 production
+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 ou
>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. They
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
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 proposa
28 matches
Mail list logo