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
> > > > checkpoint.
> > >
his 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
> > > your opinion and the PMC will of course res
sh 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 zheng wang <18031...@qq.com> w
un 25, 2020 at 7:47 PM zheng wang <18031...@qq.com> wrote:
>
> > I like thecontroller.
> >
> >
> > Coordinator is a bit long for me to write and speak.
> > Manager and Admin is used somewhere yet in HBase.
> >
> >
> >
> >
> Manager and Admin is used somewhere yet in HBase.
>
>
>
>
> ----------原始邮件------
> 发件人:"Andrew Purtell" 发送时间:2020年6月26日(星期五) 上午9:08
> 收件人:"Hbase-User" 抄送:"dev" 主题:Re: [DISCUSS] Removing problematic terms from our project
I like thecontroller.
Coordinator is a bit long for me to write and speak.
Manager and Admin is used somewhere yet in HBase.
----
??:"Andrew Purtell"https://www.merriam-webster.com/dictionary/master
gt
; > > > > > > It seems to me we have, broadly speaking, consensus around
> making
> > > > > *some*
> > > > > > > > changes. I haven't seen a strong push for "break everything
> in
> > > the
> > > > > name
&
t; > > > > > of
> > > > > > > expediency" (I would personally be fine with this). So barring
> > > > > additional
> > > > > > > discussion that favors breaking changes, current approaches
> > should
> > >
> > > > > discussion that favors breaking changes, current approaches
> should
> > > > > comport
> > > > > > with our existing project compatibility goals.
> > > > > >
> > > > > > Maybe we could stop
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 to make this
s 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
> > > > to
> &
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 T
ed
> > 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.
> > >
> > >
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
> > >
> &g
>
> >
> > ------原始邮件------
> > 发件人:"Andrew Purtell" > 发送时间:2020年6月23日(星期二) 凌晨5:24
> > 收件人:"Hbase-User" > 抄送:"dev" > 主题:Re: [DISCUSS] Removing problematic terms from our project
> >
> >
> >
g <18031...@qq.com> wrote:
> >
> > > IMO, master is ok if not used with slave together.
> > >
> > >
> > > -1/+1/+1/+1
> > >
> > >
> > > --原始邮件--
> > > 发件人:"Andrew Purtell" >
her.
> >
> >
> > -1/+1/+1/+1
> >
> >
> > ------原始邮件----------
> > 发件人:"Andrew Purtell" > 发送时间:2020年6月23日(星期二) 凌晨5:24
> > 收件人:"Hbase-User" > 抄送:"dev" > 主题:Re: [DISCUSS] Removing problematic term
> 发件人:"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
> alignme
IMO, master is ok if not used with slave together.
-1/+1/+1/+1
----
??:"Andrew Purtell"https://www.merriam-webster.com/dictionary/master
for
examples. In particular, the progression of an artisan was from
"apprentice" to "journeyman" to "master".
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"
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
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.
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
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
31 matches
Mail list logo
