Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

e 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
> > > > 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 respectfully listen to it.
> > > >
> > > >
> > > >
> > > > On Thu, Jun 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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --原始邮件--
> > > > > 发件人:"Andrew Purtell" > > > > 发送时间:2020年6月26日(星期五) 上午9:08
> > > > > 收件人:"Hbase-User" > > > > 抄送:"dev" > > > > 主题:Re: [DISCUSS] Removing problematic terms from our project
> > > > >
> > > > >
> > > > >
> > > > >  - AdminServer (as you already have AdminClient to talk to it).
> > > > >
> > > > > Oh... I like AdminServer. AdminServer (serving admin functions)
> > and
> > > > > RegionServer (serving region data).
> > > > >
> > > > > On Thu, Jun 25, 2020 at 4:46 PM Andrey Elenskiy
> > > > >  > > > >
> > > > >   Is there a word that's not "master" and not "coordinator"
> > > that
> > > > > is clear
> > > > >  and
> > > > >  suitable for (diverse, polyglot) community?
> > > > > 
> > > > >  There are also:
> > > > >  - captain (sounds pretty close to "master" without the
> negative
> > > side
> > > > > and it
> > > > >  should be relatable around the world)
> > > > >  - conductor (as in orchestra)
> > > > >  - controller (in kafka controller assigns partitions)
> > > > >  - RegionDriver (more relevant to what it's actually doing in
> > hbase
> > > > and
> > > > >  borrowed from PlacementDrive of TiKV)
> > > > >  - AdminServer (as you already have AdminClient to talk to it).
> > > > > 
> > > > >  On Thu, Jun 25, 2020 at 3:49 PM Sean Busbey <
> bus...@apache.org
> > > 
> > > > > wrote:
> > > > > 
> > > > >   How about "manager"?
> > > > >  
> > > > >   (It would help me if folks could explain what is lacking
> in
> > > > >  "coordinator".)
> > > > >  
> > > > >   On Thu, Jun 25, 2020, 13:32 Nick Dimiduk <
> > > ndimi...@apache.org
> > > > 
> > > > > wrote:
> > > > >  
> > > > >On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) <
> > > > > palomino...@gmail.com
> > > > >wrote:
> > > > >   
> > > > > -0/+1/+1/+1
> > > > >
> > > > > I’m the one who asked whether ‘master’ is safe
> to
> > > use
> > > > > without ‘slave’
> > > > >   in
> > > > > the private list.
> > > > >
> > > > > I’m still not convinced that it is really
> > necessary
> > > > > and I do not
> > > > >  think
> > > > > other words like ‘coordinator’ can fully
> describe
> > > the
> > > > > role of HMaster
> > > > >   in
> > > > > HBase. HBase is more than 10 years old. In the
> > > > context
> > > > > of HBase, the
> > > > >   word
> > > > > ‘HMaster’ has its own meaning. Changing the
> name
> > > will
> > > > > hurt our users
> > > > >   and
> > > > > make them confusing, especially for us non
> native
> > > > > English speakers...
> > > > > 

Re: [DISCUSS] Removing problematic terms from our project

[Bryan Beaudreault]

Sorry Andrew, I think I misinterpreted aspects of your last summary. It
seemed like maybe there were still open questions and I was mostly just
curious if something had been (or should be) captured anywhere else. Your
new summary helps clarify the conclusion, thanks for providing it.

On Wed, Sep 29, 2021 at 1:34 PM Andrew Purtell  wrote:

> Bryan,
>
> Let me paraphrase the resolution of this discussion from the PMC
> perspective: We are, broadly speaking, supportive of changes to improve
> conscious language choices. Our project uses some words with known
> controversial context. Unfortunately one word in particular, "master", does
> not have a consensus that it is or isn't a valid term of art, and in any
> case is deeply embedded in API and configuration contexts. Other terms,
> like "slave", have consensus on removal. We would, generally speaking,
> welcome for review any patches that change conscious language choices for
> the better. The proposer of the patch can explain the context of the change
> to help make the case it should be applied. The PMC would also provide
> support, in the form of release management and voting, for necessary
> deprecation-release-removal-release cycles where termonology changes impact
> one or more of our compatibility guidelines.
>
> What has been missing since this thread closed with this conclusion?
>
> Actual patches.
>
> It's quite easy to advocate someone *else* make language changes.
>
>
>
> On Wed, Sep 29, 2021 at 5:26 AM Bryan Beaudreault
>  wrote:
>
> > Sorry to revive a very old thread, but I just stumbled across this and
> > don't see a clear resolution. I wonder if we should create a JIRA from
> > Andrew's summary and treat that as an umbrella encompassing the original
> 3
> > JIRAs? I'm also cognizant of the fact that there are rumblings of doing
> an
> > initial 3.0 release, and I see above there was a proposal to deprecate
> in 3
> > and release in 4. I imagine we're slowly running out of time to make that
> > change.
> >
> > If I missed a JIRA somewhere, maybe we can put a link here for posterity.
> >
> > On Fri, Jun 26, 2020 at 2:35 PM Andrew Purtell 
> > wrote:
> >
> > > Circling back after more inputs, if we use this as a description of the
> > > proposals:
> > >
> > > 1. Replace "master"/"hmaster" with ???, this one has by far the most
> > > significant impact and both opinion and interpretation on this one is
> > > mixed.
> > >
> > > 2. Replace "slave" with "follower", seems to impact the cross cluster
> > > replication subsystem only.
> > >
> > > 3. Replace "black list" with "deny list".
> > >
> > > 4. Replace "white list" with "accept list".
> > >
> > > Then by my read of the responses we have consensus to do #2, #3, and
> #4.
> > > They were not controversial. JIRAs and patches will be welcome. Seems
> > > pretty clear committers and PMC will approve and do what is needed to
> > > complete any necessary deprecation cycle.
> > >
> > > Regarding #1, opinion is mixed. By my read I also think committers and
> > PMC
> > > will approve patches and do what is needed to complete any necessary
> > > deprecation cycle for this one too. Enough PMC members expressed
> support
> > to
> > > successfully vote on a release (although not if there were to be
> opposing
> > > votes). If a contributor were to open a JIRA and provide patches for
> > this,
> > > there would be 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
> > > 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 respectfully listen to it.
> > >
> > >
> > >
> > > On Thu, Jun 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.
> > > >
> > > >
> > > >
> > > >
> > > >

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

Bryan,

Let me paraphrase the resolution of this discussion from the PMC
perspective: We are, broadly speaking, supportive of changes to improve
conscious language choices. Our project uses some words with known
controversial context. Unfortunately one word in particular, "master", does
not have a consensus that it is or isn't a valid term of art, and in any
case is deeply embedded in API and configuration contexts. Other terms,
like "slave", have consensus on removal. We would, generally speaking,
welcome for review any patches that change conscious language choices for
the better. The proposer of the patch can explain the context of the change
to help make the case it should be applied. The PMC would also provide
support, in the form of release management and voting, for necessary
deprecation-release-removal-release cycles where termonology changes impact
one or more of our compatibility guidelines.

What has been missing since this thread closed with this conclusion?

Actual patches.

It's quite easy to advocate someone *else* make language changes.



On Wed, Sep 29, 2021 at 5:26 AM Bryan Beaudreault
 wrote:

> Sorry to revive a very old thread, but I just stumbled across this and
> don't see a clear resolution. I wonder if we should create a JIRA from
> Andrew's summary and treat that as an umbrella encompassing the original 3
> JIRAs? I'm also cognizant of the fact that there are rumblings of doing an
> initial 3.0 release, and I see above there was a proposal to deprecate in 3
> and release in 4. I imagine we're slowly running out of time to make that
> change.
>
> If I missed a JIRA somewhere, maybe we can put a link here for posterity.
>
> On Fri, Jun 26, 2020 at 2:35 PM Andrew Purtell 
> wrote:
>
> > Circling back after more inputs, if we use this as a description of the
> > proposals:
> >
> > 1. Replace "master"/"hmaster" with ???, this one has by far the most
> > significant impact and both opinion and interpretation on this one is
> > mixed.
> >
> > 2. Replace "slave" with "follower", seems to impact the cross cluster
> > replication subsystem only.
> >
> > 3. Replace "black list" with "deny list".
> >
> > 4. Replace "white list" with "accept list".
> >
> > Then by my read of the responses we have consensus to do #2, #3, and #4.
> > They were not controversial. JIRAs and patches will be welcome. Seems
> > pretty clear committers and PMC will approve and do what is needed to
> > complete any necessary deprecation cycle.
> >
> > Regarding #1, opinion is mixed. By my read I also think committers and
> PMC
> > will approve patches and do what is needed to complete any necessary
> > deprecation cycle for this one too. Enough PMC members expressed support
> to
> > successfully vote on a release (although not if there were to be opposing
> > votes). If a contributor were to open a JIRA and provide patches for
> this,
> > there would be 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
> > 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 respectfully listen to it.
> >
> >
> >
> > On Thu, Jun 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.
> > >
> > >
> > >
> > >
> > > --原始邮件--
> > > 发件人:"Andrew Purtell" > > 发送时间:2020年6月26日(星期五) 上午9:08
> > > 收件人:"Hbase-User" > > 抄送:"dev" > > 主题:Re: [DISCUSS] Removing problematic terms from our project
> > >
> > >
> > >
> > >  - AdminServer (as you already have AdminClient to talk to it).
> > >
> > > Oh... I like AdminServer. AdminServer (serving admin functions) and
> > > RegionServer (serving region data).
> > >
> > > On Thu, Jun 25, 2020 at 4:46 PM Andrey Elenskiy
> > >  > >
> > >   Is there a word that's not "master" and not "coordinator"
> that
> > > is clear
> > >  and
> > >

Re: [DISCUSS] Removing problematic terms from our project

[Bryan Beaudreault]

Sorry to revive a very old thread, but I just stumbled across this and
don't see a clear resolution. I wonder if we should create a JIRA from
Andrew's summary and treat that as an umbrella encompassing the original 3
JIRAs? I'm also cognizant of the fact that there are rumblings of doing an
initial 3.0 release, and I see above there was a proposal to deprecate in 3
and release in 4. I imagine we're slowly running out of time to make that
change.

If I missed a JIRA somewhere, maybe we can put a link here for posterity.

On Fri, Jun 26, 2020 at 2:35 PM Andrew Purtell  wrote:

> Circling back after more inputs, if we use this as a description of the
> proposals:
>
> 1. Replace "master"/"hmaster" with ???, this one has by far the most
> significant impact and both opinion and interpretation on this one is
> mixed.
>
> 2. Replace "slave" with "follower", seems to impact the cross cluster
> replication subsystem only.
>
> 3. Replace "black list" with "deny list".
>
> 4. Replace "white list" with "accept list".
>
> Then by my read of the responses we have consensus to do #2, #3, and #4.
> They were not controversial. JIRAs and patches will be welcome. Seems
> pretty clear committers and PMC will approve and do what is needed to
> complete any necessary deprecation cycle.
>
> Regarding #1, opinion is mixed. By my read I also think committers and PMC
> will approve patches and do what is needed to complete any necessary
> deprecation cycle for this one too. Enough PMC members expressed support to
> successfully vote on a release (although not if there were to be opposing
> votes). If a contributor were to open a JIRA and provide patches for this,
> there would be 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
> 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 respectfully listen to it.
>
>
>
> On Thu, Jun 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.
> >
> >
> >
> >
> > --原始邮件--
> > 发件人:"Andrew Purtell" > 发送时间:2020年6月26日(星期五) 上午9:08
> > 收件人:"Hbase-User" > 抄送:"dev" > 主题:Re: [DISCUSS] Removing problematic terms from our project
> >
> >
> >
> >  - AdminServer (as you already have AdminClient to talk to it).
> >
> > Oh... I like AdminServer. AdminServer (serving admin functions) and
> > RegionServer (serving region data).
> >
> > On Thu, Jun 25, 2020 at 4:46 PM Andrey Elenskiy
> >  >
> >   Is there a word that's not "master" and not "coordinator" that
> > is clear
> >  and
> >  suitable for (diverse, polyglot) community?
> > 
> >  There are also:
> >  - captain (sounds pretty close to "master" without the negative side
> > and it
> >  should be relatable around the world)
> >  - conductor (as in orchestra)
> >  - controller (in kafka controller assigns partitions)
> >  - RegionDriver (more relevant to what it's actually doing in hbase
> and
> >  borrowed from PlacementDrive of TiKV)
> >  - AdminServer (as you already have AdminClient to talk to it).
> > 
> >  On Thu, Jun 25, 2020 at 3:49 PM Sean Busbey  > wrote:
> > 
> >   How about "manager"?
> >  
> >   (It would help me if folks could explain what is lacking in
> >  "coordinator".)
> >  
> >   On Thu, Jun 25, 2020, 13:32 Nick Dimiduk  
> > wrote:
> >  
> >On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) <
> > palomino...@gmail.com
> >wrote:
> >   
> > -0/+1/+1/+1
> >
> > I’m the one who asked whether ‘master’ is safe to use
> > without ‘slave’
> >   in
> > the private list.
> >
> > I’m still not convinced that it is really necessary
> > and I do not
> >  think
> > other words like ‘coordinator’ can fully describe the
> > role of HMaster
> >   in
> > HBase. HBase is more than 10 years old. In the
> context
> > of HBase, the
> >   word
> > ‘HMaster’ has its own meani

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

Circling back after more inputs, if we use this as a description of the
proposals:

1. Replace "master"/"hmaster" with ???, this one has by far the most
significant impact and both opinion and interpretation on this one is mixed.

2. Replace "slave" with "follower", seems to impact the cross cluster
replication subsystem only.

3. Replace "black list" with "deny list".

4. Replace "white list" with "accept list".

Then by my read of the responses we have consensus to do #2, #3, and #4.
They were not controversial. JIRAs and patches will be welcome. Seems
pretty clear committers and PMC will approve and do what is needed to
complete any necessary deprecation cycle.

Regarding #1, opinion is mixed. By my read I also think committers and PMC
will approve patches and do what is needed to complete any necessary
deprecation cycle for this one too. Enough PMC members expressed support to
successfully vote on a release (although not if there were to be opposing
votes). If a contributor were to open a JIRA and provide patches for this,
there would be 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
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 respectfully listen to it.



On Thu, Jun 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.
>
>
>
>
> ----------原始邮件------
> 发件人:"Andrew Purtell" 发送时间:2020年6月26日(星期五) 上午9:08
> 收件人:"Hbase-User" 抄送:"dev" 主题:Re: [DISCUSS] Removing problematic terms from our project
>
>
>
>  - AdminServer (as you already have AdminClient to talk to it).
>
> Oh... I like AdminServer. AdminServer (serving admin functions) and
> RegionServer (serving region data).
>
> On Thu, Jun 25, 2020 at 4:46 PM Andrey Elenskiy
> 
>   Is there a word that's not "master" and not "coordinator" that
> is clear
>  and
>  suitable for (diverse, polyglot) community?
> 
>  There are also:
>  - captain (sounds pretty close to "master" without the negative side
> and it
>  should be relatable around the world)
>  - conductor (as in orchestra)
>  - controller (in kafka controller assigns partitions)
>  - RegionDriver (more relevant to what it's actually doing in hbase and
>  borrowed from PlacementDrive of TiKV)
>  - AdminServer (as you already have AdminClient to talk to it).
> 
>  On Thu, Jun 25, 2020 at 3:49 PM Sean Busbey  wrote:
> 
>   How about "manager"?
>  
>   (It would help me if folks could explain what is lacking in
>  "coordinator".)
>  
>   On Thu, Jun 25, 2020, 13:32 Nick Dimiduk  wrote:
>  
>On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) <
> palomino...@gmail.com
>wrote:
>   
> -0/+1/+1/+1
>
> I’m the one who asked whether ‘master’ is safe to use
> without ‘slave’
>   in
> the private list.
>
> I’m still not convinced that it is really necessary
> and I do not
>  think
> other words like ‘coordinator’ can fully describe the
> role of HMaster
>   in
> HBase. HBase is more than 10 years old. In the context
> of HBase, the
>   word
> ‘HMaster’ has its own meaning. Changing the name will
> hurt our users
>   and
> make them confusing, especially for us non native
> English speakers...
>
>   
>Is there a word that's not "master" and not "coordinator"
> that is clear
>   and
>suitable for (diverse, polyglot) community?
>   
>Stack 
>  +1/+1/+1/+1 where hbase3 adds the deprecation and
> hbase4 follows
>   hbase3
>  soon after sounds good to me. I'm up for working
> on this.
>  S
> 
>  On Wed, Jun 24, 2020 at 2:26 PM Xu Cang <
> xuc...@apache.org wrote:
> 
>   Strongly agree with what Nick said here:
>  
>   " 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, On the contrary,
> we have much to gain
>   by
>   encouraging
>   contributions from as many people as
> possible."
>  
>   +1 to Andrew's proposal.
>  
> 

Re: [DISCUSS] Removing problematic terms from our project

[Andrey Elenskiy]

changes. I haven't seen a strong push for "break everything in
> > the
> > > > name
> > > > > > of
> > > > > > > expediency" (I would personally be fine with this). So barring
> > > > > additional
> > > > > > > discussion that favors breaking changes, current approaches
> > should
> > > > > > comport
> > > > > > > with our existing project compatibility goals.
> > > > > > >
> > > > > > > Maybe we could stop talking about what-ifs and look at actual
> > > > practical
> > > > > > > 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
> > > > > > 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, 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 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" with ??? ("coordinator" is one
> > > > option),
> > > > > > > this
> > > > > > > > one has by far the most significant impact and both opinion
> and
> > > > > > > > interpretation on this one is mixed.
> > > > > > > >
> > > > > > > > 2. Replace "slave" with "follower", seems to impact the cross
> > > > cluster
> > > > > > > > replication subsystem only.
> > > > > > > >
> > > > > > > > 3. Replace "black list" with "deny list".
> > > > > > > >
> > > > > > > > 4. Replace "white list" with "accept list".
> > > > > > > >
> > > > > > > > Perhaps if you are inclined to respond with a +1/-1/+0/-0, it
> > > would
> > > > > be
> > > > > > > > useful to give such an indication for each line item above.
> Or,
> > > > offer
> > > > > > > > alternative proposals. Or, if you have a singular opinion,
> > that's
> > > > > fine
> > > > > > > too.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby <
> > > > gjac...@apache.org
> > > > > > 
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >  For most 

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

ould have daemons called “coordinator” and “region
> > > server”.
> > > > > > >
> > > > > > > To me, “master” as in “master branch” does not carry the same
> > > > baggage,
> > > > > > but
> > > > > > > I’m also in favor changing the name of our default branch to a
> > word
> > > > > that
> > > > > > is
> > > > > > > less conflicted. I see nothing that we gain as a community by
> > > > > continuing
> > > > > > to
> > > > > > > use this word.
> > > > > > >
> > > > > > > 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
> > > > > > > of
> > > > > > > > expediency" (I would personally be fine with this). So
> barring
> > > > > > additional
> > > > > > > > discussion that favors breaking changes, current approaches
> > > should
> > > > > > > comport
> > > > > > > > with our existing project compatibility goals.
> > > > > > > >
> > > > > > > > Maybe we could stop talking about what-ifs and look at actual
> > > > > practical
> > > > > > > > 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
> > > > > > > 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, 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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" with ??? ("coordinator" is
> one
> > > > > option),
> > > > > > > > this
> > > > > > > > > one has by far the most significant impact and both opinion
> > and
> > > > > > > > > interpretation on this one is mixed.
> > > > > > > > >
> > > > > > > > > 2. Replace "slave" with "follower", seems to impact the
> cross
> > > > &g

Re: [DISCUSS] Removing problematic terms from our project

[Sean Busbey]

How about "manager"?

(It would help me if folks could explain what is lacking in "coordinator".)

On Thu, Jun 25, 2020, 13:32 Nick Dimiduk  wrote:

> On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
> wrote:
>
> > -0/+1/+1/+1
> >
> > I’m the one who asked whether ‘master’ is safe to use without ‘slave’ in
> > the private list.
> >
> > I’m still not convinced that it is really necessary and I do not think
> > other words like ‘coordinator’ can fully describe the role of HMaster in
> > HBase. HBase is more than 10 years old. In the context of HBase, the word
> > ‘HMaster’ has its own meaning. Changing the name will hurt our users and
> > make them confusing, especially for us non native English speakers...
> >
>
> Is there a word that's not "master" and not "coordinator" that is clear and
> suitable for (diverse, polyglot) community?
>
> Stack 于2020年6月25日 周四06:34写道：
> >
> > > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
> > > soon after sounds good to me. I'm up for working on this.
> > > S
> > >
> > > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> > >
> > > > Strongly agree with what Nick said here:
> > > >
> > > >  " 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, On the contrary, we have much to gain by
> > > > encouraging
> > > > contributions from as many people as possible."
> > > >
> > > > +1 to Andrew's proposal.
> > > >
> > > > It might be good to have a source of truth web page or README file
> for
> > > > developers and users to refer to regarding all naming transitions.
> It's
> > > > going to help both developers changing the code and users looking for
> > > some
> > > > answers online that use old namings.
> > > >
> > > > Xu
> > > >
> > > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> > > wrote:
> > > >
> > > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey 
> wrote:
> > > > >
> > > > > > I would like to make sure I am emphatically clear that "master"
> by
> > > > itself
> > > > > > is not okay if the context is the same as what would normally be
> a
> > > > > > master/slave context. Furthermore our use of master is clearly
> > such a
> > > > > > context.
> > > > >
> > > > >
> > > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > > master/slave
> > > > > baggage. As an alternative, I prefer the term “coordinator” over
> > > > “leader”.
> > > > > Thus we would have daemons called “coordinator” and “region
> server”.
> > > > >
> > > > > To me, “master” as in “master branch” does not carry the same
> > baggage,
> > > > but
> > > > > I’m also in favor changing the name of our default branch to a word
> > > that
> > > > is
> > > > > less conflicted. I see nothing that we gain as a community by
> > > continuing
> > > > to
> > > > > use this word.
> > > > >
> > > > > 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
> > > > > of
> > > > > > expediency" (I would personally be fine with this). So barring
> > > > additional
> > > > > > discussion that favors breaking changes, current approaches
> should
> > > > > comport
> > > > > > with our existing project compatibility goals.
> > > > > >
> > > > > > Maybe we could stop talking about what-ifs and look at actual
> > > practical
> > > > > > 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
> > > > > to
> > > > > > in 3.0.0 to make this happen" then it would be good to speak up.
> > &g

Re: [DISCUSS] Removing problematic terms from our project

[Nick Dimiduk]

On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
wrote:

> -0/+1/+1/+1
>
> I’m the one who asked whether ‘master’ is safe to use without ‘slave’ in
> the private list.
>
> I’m still not convinced that it is really necessary and I do not think
> other words like ‘coordinator’ can fully describe the role of HMaster in
> HBase. HBase is more than 10 years old. In the context of HBase, the word
> ‘HMaster’ has its own meaning. Changing the name will hurt our users and
> make them confusing, especially for us non native English speakers...
>

Is there a word that's not "master" and not "coordinator" that is clear and
suitable for (diverse, polyglot) community?

Stack 于2020年6月25日 周四06:34写道：
>
> > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
> > soon after sounds good to me. I'm up for working on this.
> > S
> >
> > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> >
> > > Strongly agree with what Nick said here:
> > >
> > >  " 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, On the contrary, we have much to gain by
> > > encouraging
> > > contributions from as many people as possible."
> > >
> > > +1 to Andrew's proposal.
> > >
> > > It might be good to have a source of truth web page or README file for
> > > developers and users to refer to regarding all naming transitions. It's
> > > going to help both developers changing the code and users looking for
> > some
> > > answers online that use old namings.
> > >
> > > Xu
> > >
> > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> > wrote:
> > >
> > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:
> > > >
> > > > > I would like to make sure I am emphatically clear that "master" by
> > > itself
> > > > > is not okay if the context is the same as what would normally be a
> > > > > master/slave context. Furthermore our use of master is clearly
> such a
> > > > > context.
> > > >
> > > >
> > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > master/slave
> > > > baggage. As an alternative, I prefer the term “coordinator” over
> > > “leader”.
> > > > Thus we would have daemons called “coordinator” and “region server”.
> > > >
> > > > To me, “master” as in “master branch” does not carry the same
> baggage,
> > > but
> > > > I’m also in favor changing the name of our default branch to a word
> > that
> > > is
> > > > less conflicted. I see nothing that we gain as a community by
> > continuing
> > > to
> > > > use this word.
> > > >
> > > > 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
> > > > of
> > > > > expediency" (I would personally be fine with this). So barring
> > > additional
> > > > > discussion that favors breaking changes, current approaches should
> > > > comport
> > > > > with our existing project compatibility goals.
> > > > >
> > > > > Maybe we could stop talking about what-ifs and look at actual
> > practical
> > > > > 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
> > > > 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, 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

Re: [DISCUSS] Removing problematic terms from our project

[Duo Zhang]

-0/+1/+1/+1

I’m the one who asked whether ‘master’ is safe to use without ‘slave’ in
the private list.

I’m still not convinced that it is really necessary and I do not think
other words like ‘coordinator’ can fully describe the role of HMaster in
HBase. HBase is more than 10 years old. In the context of HBase, the word
‘HMaster’ has its own meaning. Changing the name will hurt our users and
make them confusing, especially for us non native English speakers...

Thanks.

Stack 于2020年6月25日 周四06:34写道：

> +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
> soon after sounds good to me. I'm up for working on this.
> S
>
> On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
>
> > Strongly agree with what Nick said here:
> >
> >  " 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, On the contrary, we have much to gain by
> > encouraging
> > contributions from as many people as possible."
> >
> > +1 to Andrew's proposal.
> >
> > It might be good to have a source of truth web page or README file for
> > developers and users to refer to regarding all naming transitions. It's
> > going to help both developers changing the code and users looking for
> some
> > answers online that use old namings.
> >
> > Xu
> >
> > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> wrote:
> >
> > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:
> > >
> > > > I would like to make sure I am emphatically clear that "master" by
> > itself
> > > > is not okay if the context is the same as what would normally be a
> > > > master/slave context. Furthermore our use of master is clearly such a
> > > > context.
> > >
> > >
> > > I agree: to me “Master”, as in “HMaster” caries with it the
> master/slave
> > > baggage. As an alternative, I prefer the term “coordinator” over
> > “leader”.
> > > Thus we would have daemons called “coordinator” and “region server”.
> > >
> > > To me, “master” as in “master branch” does not carry the same baggage,
> > but
> > > I’m also in favor changing the name of our default branch to a word
> that
> > is
> > > less conflicted. I see nothing that we gain as a community by
> continuing
> > to
> > > use this word.
> > >
> > > 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
> > > of
> > > > expediency" (I would personally be fine with this). So barring
> > additional
> > > > discussion that favors breaking changes, current approaches should
> > > comport
> > > > with our existing project compatibility goals.
> > > >
> > > > Maybe we could stop talking about what-ifs and look at actual
> practical
> > > > 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
> > > 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, 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
> > > > >
> > > > >
> > > > >
> > > > > 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 i

Re: [DISCUSS] Removing problematic terms from our project

[Stack]

+1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
soon after sounds good to me. I'm up for working on this.
S

On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:

> Strongly agree with what Nick said here:
>
>  " 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, On the contrary, we have much to gain by
> encouraging
> contributions from as many people as possible."
>
> +1 to Andrew's proposal.
>
> It might be good to have a source of truth web page or README file for
> developers and users to refer to regarding all naming transitions. It's
> going to help both developers changing the code and users looking for some
> answers online that use old namings.
>
> Xu
>
> On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk  wrote:
>
> > On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:
> >
> > > I would like to make sure I am emphatically clear that "master" by
> itself
> > > is not okay if the context is the same as what would normally be a
> > > master/slave context. Furthermore our use of master is clearly such a
> > > context.
> >
> >
> > I agree: to me “Master”, as in “HMaster” caries with it the master/slave
> > baggage. As an alternative, I prefer the term “coordinator” over
> “leader”.
> > Thus we would have daemons called “coordinator” and “region server”.
> >
> > To me, “master” as in “master branch” does not carry the same baggage,
> but
> > I’m also in favor changing the name of our default branch to a word that
> is
> > less conflicted. I see nothing that we gain as a community by continuing
> to
> > use this word.
> >
> > 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
> > of
> > > expediency" (I would personally be fine with this). So barring
> additional
> > > discussion that favors breaking changes, current approaches should
> > comport
> > > with our existing project compatibility goals.
> > >
> > > Maybe we could stop talking about what-ifs and look at actual practical
> > > 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
> > 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, 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
> > > >
> > > >
> > > >
> > > > 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" with ??? ("coordinator" is one option),
> > > this
> > > > one has by far the most significant impact and both opinion and
> > > > interpretation on this one is mixed.
> > > >
> > > > 2. Replace "slave" with "follower", seems to impact the cross cluster
> > > > replication subsystem only.
> > > >
> > > > 3. Replace "black list" with "deny list".
> > > >
> > > > 4. Replace "white list" with "accept list".
> > > >
> > > > Perhaps if you are inclined to respond with a +1/-1/+0/-0, it would
> be
> > > > useful to give such an indication for each line item above. Or, offer
> > > > alternative proposals. Or, if you have a singular opinion, that's
> fine
> > > too.
>

Re: [DISCUSS] Removing problematic terms from our project

[Xu Cang]

Strongly agree with what Nick said here:

 " 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, On the contrary, we have much to gain by
encouraging
contributions from as many people as possible."

+1 to Andrew's proposal.

It might be good to have a source of truth web page or README file for
developers and users to refer to regarding all naming transitions. It's
going to help both developers changing the code and users looking for some
answers online that use old namings.

Xu

On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk  wrote:

> On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:
>
> > I would like to make sure I am emphatically clear that "master" by itself
> > is not okay if the context is the same as what would normally be a
> > master/slave context. Furthermore our use of master is clearly such a
> > context.
>
>
> I agree: to me “Master”, as in “HMaster” caries with it the master/slave
> baggage. As an alternative, I prefer the term “coordinator” over “leader”.
> Thus we would have daemons called “coordinator” and “region server”.
>
> To me, “master” as in “master branch” does not carry the same baggage, but
> I’m also in favor changing the name of our default branch to a word that is
> less conflicted. I see nothing that we gain as a community by continuing to
> use this word.
>
> 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
> of
> > expediency" (I would personally be fine with this). So barring additional
> > discussion that favors breaking changes, current approaches should
> comport
> > with our existing project compatibility goals.
> >
> > Maybe we could stop talking about what-ifs and look at actual practical
> > 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
> 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, 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
> > >
> > >
> > >
> > > 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" with ??? ("coordinator" is one option),
> > this
> > > one has by far the most significant impact and both opinion and
> > > interpretation on this one is mixed.
> > >
> > > 2. Replace "slave" with "follower", seems to impact the cross cluster
> > > replication subsystem only.
> > >
> > > 3. Replace "black list" with "deny list".
> > >
> > > 4. Replace "white list" with "accept list".
> > >
> > > Perhaps if you are inclined to respond with a +1/-1/+0/-0, it would be
> > > useful to give such an indication for each line item above. Or, offer
> > > alternative proposals. Or, if you have a singular opinion, that's fine
> > too.
> > >
> > >
> > >
> > > On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby  
> > > wrote:
> > >
> > >  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 similar. Unlike "slave", which is negative in any
> context,
> > >  "master" has ma

Re: [DISCUSS] Removing problematic terms from our project

[Nick Dimiduk]

On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:

> I would like to make sure I am emphatically clear that "master" by itself
> is not okay if the context is the same as what would normally be a
> master/slave context. Furthermore our use of master is clearly such a
> context.


I agree: to me “Master”, as in “HMaster” caries with it the master/slave
baggage. As an alternative, I prefer the term “coordinator” over “leader”.
Thus we would have daemons called “coordinator” and “region server”.

To me, “master” as in “master branch” does not carry the same baggage, but
I’m also in favor changing the name of our default branch to a word that is
less conflicted. I see nothing that we gain as a community by continuing to
use this word.

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 of
> expediency" (I would personally be fine with this). So barring additional
> discussion that favors breaking changes, current approaches should comport
> with our existing project compatibility goals.
>
> Maybe we could stop talking about what-ifs and look at actual practical
> 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 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, 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
> >
> >
> >
> > 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" with ??? ("coordinator" is one option),
> this
> > one has by far the most significant impact and both opinion and
> > interpretation on this one is mixed.
> >
> > 2. Replace "slave" with "follower", seems to impact the cross cluster
> > replication subsystem only.
> >
> > 3. Replace "black list" with "deny list".
> >
> > 4. Replace "white list" with "accept list".
> >
> > Perhaps if you are inclined to respond with a +1/-1/+0/-0, it would be
> > useful to give such an indication for each line item above. Or, offer
> > alternative proposals. Or, if you have a singular opinion, that's fine
> too.
> >
> >
> >
> > On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby  > wrote:
> >
> >  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 similar. Unlike "slave", which is negative in any context,
> >  "master" has many definitions, including some common ones which do
> not
> >  appear problematic. See
> > https://www.merriam-webster.com/dictionary/master
> >  <https://www.merriam-webster.com/dictionary/master>; for
> >  examples. In particular, the progression of an artisan was from
> >  "apprentice" to "journeyman" to "master". A master smith, carpenter,
> > or
> >  artist would run a shop managing lots of workers and apprentices who
> > would
> >  hope to become masters of their own someday. So "master" and
> "worker"
> > can
> >  still go together.
> > 
> >  Since it's the least problematic term, and by far the hardest term
> to
> >  change (both within HBase and with effects on downstream projects
> > such as
> >  Ambari), I'm -0 (nonbinding) on changing "master".
> > 
> >  Geoffrey
> > 
> >  On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
> >   > 
> >   +1 to renaming.
> >  
> >  
> >   Rushabh Shah
> > 

Re: [DISCUSS] Removing problematic terms from our project

[Sean Busbey]

I would like to make sure I am emphatically clear that "master" by itself
is not okay if the context is the same as what would normally be a
master/slave context. Furthermore our use of master is clearly such a
context.

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 of
expediency" (I would personally be fine with this). So barring additional
discussion that favors breaking changes, current approaches should comport
with our existing project compatibility goals.

Maybe we could stop talking about what-ifs and look at actual practical
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 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, 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
>
>
>
> 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" with ??? ("coordinator" is one option), this
> one has by far the most significant impact and both opinion and
> interpretation on this one is mixed.
>
> 2. Replace "slave" with "follower", seems to impact the cross cluster
> replication subsystem only.
>
> 3. Replace "black list" with "deny list".
>
> 4. Replace "white list" with "accept list".
>
> Perhaps if you are inclined to respond with a +1/-1/+0/-0, it would be
> useful to give such an indication for each line item above. Or, offer
> alternative proposals. Or, if you have a singular opinion, that's fine too.
>
>
>
> On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby  wrote:
>
>  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 similar. Unlike "slave", which is negative in any context,
>  "master" has many definitions, including some common ones which do not
>  appear problematic. See
> https://www.merriam-webster.com/dictionary/master
>  <https://www.merriam-webster.com/dictionary/master>; for
>  examples. In particular, the progression of an artisan was from
>  "apprentice" to "journeyman" to "master". A master smith, carpenter,
> or
>  artist would run a shop managing lots of workers and apprentices who
> would
>  hope to become masters of their own someday. So "master" and "worker"
> can
>  still go together.
> 
>  Since it's the least problematic term, and by far the hardest term to
>  change (both within HBase and with effects on downstream projects
> such as
>  Ambari), I'm -0 (nonbinding) on changing "master".
> 
>  Geoffrey
> 
>  On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
>   
>   +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
> 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 make me personally less
> enthusiastic about
> contributing. That's enough friction for me to
> advocate removing
>  them.
>
> AFAICT reworking our replication stuff in terms of
> "active" and
>   "passive"
> clusters did not result in a big spike of folks asking
> new questions
>about
> where authority f

Re: [DISCUSS] Removing problematic terms from our project

[Esteban Gutierrez]

+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
> 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 changing to coordinator since
> in my mind this is actually a more clear definition of what HMaster does.
>
> On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby 
> wrote:
>
> > 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 similar. Unlike "slave", which is negative in any context,
> > "master" has many definitions, including some common ones which do not
> > appear problematic. See
> https://www.merriam-webster.com/dictionary/master
> > for
> > examples. In particular, the progression of an artisan was from
> > "apprentice" to "journeyman" to "master". A master smith, carpenter, or
> > artist would run a shop managing lots of workers and apprentices who
> would
> > hope to become masters of their own someday. So "master" and "worker" can
> > still go together.
> >
> > Since it's the least problematic term, and by far the hardest term to
> > change (both within HBase and with effects on downstream projects such as
> > Ambari), I'm -0 (nonbinding) on changing "master".
> >
> > Geoffrey
> >
> > On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
> >  wrote:
> >
> > > +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
> > > > > 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 make me personally less enthusiastic about
> > > > > contributing. That's enough friction for me to advocate removing
> > them.
> > > > >
> > > > > AFAICT reworking our replication stuff in terms of "active" and
> > > "passive"
> > > > > clusters did not result in a big spike of folks asking new
> questions
> > > > about
> > > > > where authority for state was.
> > > > >
> > > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> > > wrote:
> > > > >
> > > > >> 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 discussion on private@ on June 9,
> 2020
> > > > with an
> > > > >> observation of this activity and this suggestion:
> > > > >>
> > > > >> There is a renewed push back against classic technology industry
> > terms
> > > > that
> > > > >> have negative modern connotations.
> > > > >>
> > > > >> In the case of HBase, the following substitutions might be
> proposed:
> > > > >>
> > > > >> - Coordinator instead of master
> > > > >>
> > > > >> - Worker instead of slave
> > > > >>
> > > > >> Recommendations for these additional substitutions also come up in
> > > this
> > > > >> type of discussion:
> > > > >>
> > > > >> - Accept list instead of white list
> > > > >>
> > > > >> - Deny list instead of black list
> > > > >>
> > > > >> Unfortunately we have Master all over our code base, baked into
> > > various
> > > > >> APIs and configuration variable names, so for us the necessary
> > changes
> > > > >> amount to a new major release and deprecation cycle. It could well
> > be
> > > > worth
> > > > >> it in the long run. We exist only as long as we draw a willing and
> > > > >> sufficient contributor community. It also wouldn’t be great to
> have
> > an
> > > > >> activist fork appear somewhere, even if unlikely to be successful.
> > > > >>
> > > > >> Relevant JIRAs are:
> > > > >>
> > > > >> - HBASE-12677 <
> > https://issues.apache.org/jira/browse/HBASE-12677
> > > >:
> > > > >> Update replication docs to clarify terminology
> > > > >> - HBASE-13852 <
> > https://issues.apache.org/jira/browse/HBASE-13852
> > > >:
> > > > >> Replace master-slave terminology in book, site, and javadoc
> > with a

Re: [DISCUSS] Removing problematic terms from our project

[Mich Talebzadeh]

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 the printer of a computer) that is directly responsive
to another
4: DRUDGE , TOILER

so in the context of Hbase, number *3* is valid. In other words, a
component which is directly responsive to another, another being *master*.






LinkedIn * 
https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
*





*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Mon, 22 Jun 2020 at 22:09, Geoffrey Jacoby  wrote:

> 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 similar. Unlike "slave", which is negative in any context,
> "master" has many definitions, including some common ones which do not
> appear problematic. See https://www.merriam-webster.com/dictionary/master
> for
> examples. In particular, the progression of an artisan was from
> "apprentice" to "journeyman" to "master". A master smith, carpenter, or
> artist would run a shop managing lots of workers and apprentices who would
> hope to become masters of their own someday. So "master" and "worker" can
> still go together.
>
> Since it's the least problematic term, and by far the hardest term to
> change (both within HBase and with effects on downstream projects such as
> Ambari), I'm -0 (nonbinding) on changing "master".
>
> Geoffrey
>
> On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
>  wrote:
>
> > +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
> > > > 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 make me personally less enthusiastic about
> > > > contributing. That's enough friction for me to advocate removing
> them.
> > > >
> > > > AFAICT reworking our replication stuff in terms of "active" and
> > "passive"
> > > > clusters did not result in a big spike of folks asking new questions
> > > about
> > > > where authority for state was.
> > > >
> > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> > wrote:
> > > >
> > > >> 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 discussion on private@ on June 9, 2020
> > > with an
> > > >> observation of this activity and this suggestion:
> > > >>
> > > >> There is a renewed push back against classic technology industry
> terms
> > > that
> > > >> have negative modern connotations.
> > > >>
> > > >> In the case of HBase, the following substitutions might be proposed:
> > > >>
> > > >> - Coordinator instead of master
> > > >>
> > > >> - Worker instead of slave
> > > >>
> > > >> Recommendations for these additional substitutions also come up in
> > this
> > > >> type of discussion:
> > > >>
> > > >> - Accept list instead of white list
> > > >>
> > > >> - Deny list instead of black list
> > > >>
> > > >> Unfortunately we have Master all over our code base, baked into
> > various
> > > >> APIs and configuration variable names, so for us the necessary
> changes
> > > >> amount to a new major release and deprecation cycle. It could well
> be
> > > worth
> > > >> it in the long run. We exist only as long as we draw a willing and
> > > >> sufficient contributor community. It also wouldn’t be great to have
> an
> > > >> activist fork appear somewhere, even if unlikely to be successful.
> > > >>
> > > >> Relevant JIRAs are:
> > > >>
> > > 

Re: [DISCUSS] Removing problematic terms from our project

[Zach York]

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 changing to coordinator since
in my mind this is actually a more clear definition of what HMaster does.

On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby  wrote:

> 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 similar. Unlike "slave", which is negative in any context,
> "master" has many definitions, including some common ones which do not
> appear problematic. See https://www.merriam-webster.com/dictionary/master
> for
> examples. In particular, the progression of an artisan was from
> "apprentice" to "journeyman" to "master". A master smith, carpenter, or
> artist would run a shop managing lots of workers and apprentices who would
> hope to become masters of their own someday. So "master" and "worker" can
> still go together.
>
> Since it's the least problematic term, and by far the hardest term to
> change (both within HBase and with effects on downstream projects such as
> Ambari), I'm -0 (nonbinding) on changing "master".
>
> Geoffrey
>
> On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
>  wrote:
>
> > +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
> > > > 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 make me personally less enthusiastic about
> > > > contributing. That's enough friction for me to advocate removing
> them.
> > > >
> > > > AFAICT reworking our replication stuff in terms of "active" and
> > "passive"
> > > > clusters did not result in a big spike of folks asking new questions
> > > about
> > > > where authority for state was.
> > > >
> > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> > wrote:
> > > >
> > > >> 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 discussion on private@ on June 9, 2020
> > > with an
> > > >> observation of this activity and this suggestion:
> > > >>
> > > >> There is a renewed push back against classic technology industry
> terms
> > > that
> > > >> have negative modern connotations.
> > > >>
> > > >> In the case of HBase, the following substitutions might be proposed:
> > > >>
> > > >> - Coordinator instead of master
> > > >>
> > > >> - Worker instead of slave
> > > >>
> > > >> Recommendations for these additional substitutions also come up in
> > this
> > > >> type of discussion:
> > > >>
> > > >> - Accept list instead of white list
> > > >>
> > > >> - Deny list instead of black list
> > > >>
> > > >> Unfortunately we have Master all over our code base, baked into
> > various
> > > >> APIs and configuration variable names, so for us the necessary
> changes
> > > >> amount to a new major release and deprecation cycle. It could well
> be
> > > worth
> > > >> it in the long run. We exist only as long as we draw a willing and
> > > >> sufficient contributor community. It also wouldn’t be great to have
> an
> > > >> activist fork appear somewhere, even if unlikely to be successful.
> > > >>
> > > >> Relevant JIRAs are:
> > > >>
> > > >> - HBASE-12677 <
> https://issues.apache.org/jira/browse/HBASE-12677
> > >:
> > > >> Update replication docs to clarify terminology
> > > >> - HBASE-13852 <
> https://issues.apache.org/jira/browse/HBASE-13852
> > >:
> > > >> Replace master-slave terminology in book, site, and javadoc
> with a
> > > more
> > > >> modern vocabulary
> > > >> - HBASE-24576 <
> https://issues.apache.org/jira/browse/HBASE-24576
> > >:
> > > >> Changing "whitelist" and "blacklist" in our docs and project
> > > >>
> > > >> In response to this proposal, a member of the PMC asked if the term
> > > >> 'master' used by itself would be fine, because we only have use of
> > > 'slave'
> > > >> in replication documentation and that is easily addressed. In
> response
> > > to
> > > >> 

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

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.



On Mon, Jun 22, 2020 at 2:23 PM Mich Talebzadeh 
wrote:

> 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 the printer of a computer) that is directly responsive
> to another
> 4: DRUDGE , TOILER
> 
> so in the context of Hbase, number *3* is valid. In other words, a
> component which is directly responsive to another, another being *master*.
>
>
> 
>
>
>
> LinkedIn *
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> <
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> >*
>
>
>
>
>
> *Disclaimer:* Use it at your own risk. Any and all responsibility for any
> loss, damage or destruction of data or any other property which may arise
> from relying on this email's technical content is explicitly disclaimed.
> The author will in no case be liable for any monetary damages arising from
> such loss, damage or destruction.
>
>
>
>
> On Mon, 22 Jun 2020 at 22:09, Geoffrey Jacoby  wrote:
>
> > 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 similar. Unlike "slave", which is negative in any context,
> > "master" has many definitions, including some common ones which do not
> > appear problematic. See
> https://www.merriam-webster.com/dictionary/master
> > for
> > examples. In particular, the progression of an artisan was from
> > "apprentice" to "journeyman" to "master". A master smith, carpenter, or
> > artist would run a shop managing lots of workers and apprentices who
> would
> > hope to become masters of their own someday. So "master" and "worker" can
> > still go together.
> >
> > Since it's the least problematic term, and by far the hardest term to
> > change (both within HBase and with effects on downstream projects such as
> > Ambari), I'm -0 (nonbinding) on changing "master".
> >
> > Geoffrey
> >
> > On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
> >  wrote:
> >
> > > +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
> > > > > 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 make me personally less enthusiastic about
> > > > > contributing. That's enough friction for me to advocate removing
> > them.
> > > > >
> > > > > AFAICT reworking our replication stuff in terms of "active" and
> > > "passive"
> > > > > clusters did not result in a big spike of folks asking new
> questions
> > > > about
> > > > > where authority for state was.
> > > > >
> > > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> > > wrote:
> > > > >
> > > > >> 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 discussion on private@ on June 9,
> 2020
> > > > with an
> > > > >> observation of this activity and this suggestion:
> > > > >>
> > > > >> There is a renewed push back against classic technology industry
> > terms
> > > > that
> > > > >> have negative modern connotations.
> > > > >>
> > > > >> In the case of HBase, the following substitutions might be
> proposed:
> > > > >>
> > > > >> - Coordinator instead of master
> > > > >>
> > > > >> - Worker instead of slave
> > > > >>
> > > > >> Recommendations for these additional substitutions also come up in
> > > this
> > > > >> type of discussion:
> > > > >>
> > > > >> - Accept list instead of 

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

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" with ??? ("coordinator" is one option), this
one has by far the most significant impact and both opinion and
interpretation on this one is mixed.

2. Replace "slave" with "follower", seems to impact the cross cluster
replication subsystem only.

3. Replace "black list" with "deny list".

4. Replace "white list" with "accept list".

Perhaps if you are inclined to respond with a +1/-1/+0/-0, it would be
useful to give such an indication for each line item above. Or, offer
alternative proposals. Or, if you have a singular opinion, that's fine too.



On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby  wrote:

> 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 similar. Unlike "slave", which is negative in any context,
> "master" has many definitions, including some common ones which do not
> appear problematic. See https://www.merriam-webster.com/dictionary/master
> for
> examples. In particular, the progression of an artisan was from
> "apprentice" to "journeyman" to "master". A master smith, carpenter, or
> artist would run a shop managing lots of workers and apprentices who would
> hope to become masters of their own someday. So "master" and "worker" can
> still go together.
>
> Since it's the least problematic term, and by far the hardest term to
> change (both within HBase and with effects on downstream projects such as
> Ambari), I'm -0 (nonbinding) on changing "master".
>
> Geoffrey
>
> On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
>  wrote:
>
> > +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
> > > > 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 make me personally less enthusiastic about
> > > > contributing. That's enough friction for me to advocate removing
> them.
> > > >
> > > > AFAICT reworking our replication stuff in terms of "active" and
> > "passive"
> > > > clusters did not result in a big spike of folks asking new questions
> > > about
> > > > where authority for state was.
> > > >
> > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> > wrote:
> > > >
> > > >> 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 discussion on private@ on June 9, 2020
> > > with an
> > > >> observation of this activity and this suggestion:
> > > >>
> > > >> There is a renewed push back against classic technology industry
> terms
> > > that
> > > >> have negative modern connotations.
> > > >>
> > > >> In the case of HBase, the following substitutions might be proposed:
> > > >>
> > > >> - Coordinator instead of master
> > > >>
> > > >> - Worker instead of slave
> > > >>
> > > >> Recommendations for these additional substitutions also come up in
> > this
> > > >> type of discussion:
> > > >>
> > > >> - Accept list instead of white list
> > > >>
> > > >> - Deny list instead of black list
> > > >>
> > > >> Unfortunately we have Master all over our code base, baked into
> > various
> > > >> APIs and configuration variable names, so for us the necessary
> changes
> > > >> amount to a new major release and deprecation cycle. It could well
> be
> > > worth
> > > >> it in the long run. We exist only as long as we draw a willing and
> > > >> sufficient contributor community. It also wouldn’t be great to have
> an
> > > >> activist fork appear somewhere, even if unlikely to be successful.
> > > >>
> > > >> Relevant JIRAs are:
> > > >>
> > > >> - HBASE-12677 <
> https://issues.apache.org/jira/browse/HBASE-12677
> > >:
> > > >> Update replication docs to clarify terminology
> > > >> - HBASE-13852 <
> https://issues.apache.org/jira/browse/HBASE-13852
> > >:
> > > >> Replace master-slave terminology in book, site, and javadoc
> with a
> > > more
> > > >> modern 

Re: [DISCUSS] Removing problematic terms from our project

[Geoffrey Jacoby]

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 similar. Unlike "slave", which is negative in any context,
"master" has many definitions, including some common ones which do not
appear problematic. See https://www.merriam-webster.com/dictionary/master for
examples. In particular, the progression of an artisan was from
"apprentice" to "journeyman" to "master". A master smith, carpenter, or
artist would run a shop managing lots of workers and apprentices who would
hope to become masters of their own someday. So "master" and "worker" can
still go together.

Since it's the least problematic term, and by far the hardest term to
change (both within HBase and with effects on downstream projects such as
Ambari), I'm -0 (nonbinding) on changing "master".

Geoffrey

On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
 wrote:

> +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
> > > 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 make me personally less enthusiastic about
> > > contributing. That's enough friction for me to advocate removing them.
> > >
> > > AFAICT reworking our replication stuff in terms of "active" and
> "passive"
> > > clusters did not result in a big spike of folks asking new questions
> > about
> > > where authority for state was.
> > >
> > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> wrote:
> > >
> > >> 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 discussion on private@ on June 9, 2020
> > with an
> > >> observation of this activity and this suggestion:
> > >>
> > >> There is a renewed push back against classic technology industry terms
> > that
> > >> have negative modern connotations.
> > >>
> > >> In the case of HBase, the following substitutions might be proposed:
> > >>
> > >> - Coordinator instead of master
> > >>
> > >> - Worker instead of slave
> > >>
> > >> Recommendations for these additional substitutions also come up in
> this
> > >> type of discussion:
> > >>
> > >> - Accept list instead of white list
> > >>
> > >> - Deny list instead of black list
> > >>
> > >> Unfortunately we have Master all over our code base, baked into
> various
> > >> APIs and configuration variable names, so for us the necessary changes
> > >> amount to a new major release and deprecation cycle. It could well be
> > worth
> > >> it in the long run. We exist only as long as we draw a willing and
> > >> sufficient contributor community. It also wouldn’t be great to have an
> > >> activist fork appear somewhere, even if unlikely to be successful.
> > >>
> > >> Relevant JIRAs are:
> > >>
> > >> - HBASE-12677  >:
> > >> Update replication docs to clarify terminology
> > >> - HBASE-13852  >:
> > >> Replace master-slave terminology in book, site, and javadoc with a
> > more
> > >> modern vocabulary
> > >> - HBASE-24576  >:
> > >> Changing "whitelist" and "blacklist" in our docs and project
> > >>
> > >> In response to this proposal, a member of the PMC asked if the term
> > >> 'master' used by itself would be fine, because we only have use of
> > 'slave'
> > >> in replication documentation and that is easily addressed. In response
> > to
> > >> this question, others on the PMC suggested that even if only 'master'
> is
> > >> used, in this context it is still a problem.
> > >>
> > >> For folks who are surprised or lacking context on the details of this
> > >> discussion, one PMC member offered a link to this draft RFC as
> > background:
> > >> https://tools.ietf.org/id/draft-knodel-terminology-00.html
> > >>
> > >> There was general support for removing the term "master" / "hmaster"
> > from
> > >> our code base and using the terms "coordinator" or "leader" instead.
> In
> > the
> > >> context of replication, "worker" makes less sense and perhaps
> > "destination"
> > >> or "follower" would be more appropriate terms.
> > >>
> > >> One PMC member's 

Re: [DISCUSS] Removing problematic terms from our project

[Mich Talebzadeh]

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 lag few versions behind, in
   all likelihood, it may take few years before the changes are materialised
   5. If there is a clear majority message that we ought to change, then a
   sensible roadmap should be prepared with timelines.
   6. We should not change the things because it is fashionable. Those who
   have visited Linkedlin recently would have noticed that there are a lot of
   companies who rightly or wrongly have come out with the support of the
   current trends and equally have attracted a lot of criticism by quote "not
   being sincere"


I know I am not making myself popular but I think we ought to weigh things
up in true context.


HTH




LinkedIn * 
https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
*





*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Mon, 22 Jun 2020 at 20:14, Mich Talebzadeh 
wrote:

>
> 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
> proposal which is accepted and a proposal which is struck out (black
> pencil line).
>
> So in scientific context these are terminologies used. Terminologies
> become offensive if they are used "in the incorrect context". I don't think
> anyone in HBase or Spark community will have objections if these
> terminologies are used as before. Spark used the term in master/slave in
> Standalone mode if i recall correctly.
>
> Changing something for the sake of "now being in the limelight" does not
> make it right. So I beg to differ on this. Having said that it is indeed a
> sign of a civilised mind to entertain an idea without accepting it so
> whatever the community wishes.
>
> HTH
>
>
>
>
> LinkedIn * 
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> *
>
>
>
>
>
> *Disclaimer:* Use it at your own risk. Any and all responsibility for any
> loss, damage or destruction of data or any other property which may arise
> from relying on this email's technical content is explicitly disclaimed.
> The author will in no case be liable for any monetary damages arising from
> such loss, damage or destruction.
>
>
>
>
> On Mon, 22 Jun 2020 at 19:39, Andrew Purtell  wrote:
>
>> 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 discussion on private@ on June 9, 2020 with
>> an
>> observation of this activity and this suggestion:
>>
>> There is a renewed push back against classic technology industry terms
>> that
>> have negative modern connotations.
>>
>> In the case of HBase, the following substitutions might be proposed:
>>
>> - Coordinator instead of master
>>
>> - Worker instead of slave
>>
>> Recommendations for these additional substitutions also come up in this
>> type of discussion:
>>
>> - Accept list instead of white list
>>
>> - Deny list instead of black list
>>
>> Unfortunately we have Master all over our code base, baked into various
>> APIs and configuration variable names, so for us the necessary changes
>> amount to a new major release and deprecation cycle. It could well be
>> worth
>> it in the long run. We exist only as long as we draw a willing and
>> sufficient contributor community. It also wouldn’t be great to have an
>> activist fork appear somewhere, even if unlikely to be successful.
>>
>> Relevant JIRAs are:
>>
>>- HBASE-12677 :
>>Update replication docs to clarify terminology
>>- HBASE-13852 :
>>Replace master-slave terminology in book, site, and javadoc with a more
>>modern vocabulary
>>- HBASE-24576 :
>>Changing "whitelist" and "blacklist" in our docs and project
>>
>> In response to this proposal, a member of the PMC asked if the term
>> 

Re: [DISCUSS] Removing problematic terms from our project

[Rushabh Shah]

+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
> > 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 make me personally less enthusiastic about
> > contributing. That's enough friction for me to advocate removing them.
> >
> > AFAICT reworking our replication stuff in terms of "active" and "passive"
> > clusters did not result in a big spike of folks asking new questions
> about
> > where authority for state was.
> >
> > On Mon, Jun 22, 2020, 13:39 Andrew Purtell  wrote:
> >
> >> 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 discussion on private@ on June 9, 2020
> with an
> >> observation of this activity and this suggestion:
> >>
> >> There is a renewed push back against classic technology industry terms
> that
> >> have negative modern connotations.
> >>
> >> In the case of HBase, the following substitutions might be proposed:
> >>
> >> - Coordinator instead of master
> >>
> >> - Worker instead of slave
> >>
> >> Recommendations for these additional substitutions also come up in this
> >> type of discussion:
> >>
> >> - Accept list instead of white list
> >>
> >> - Deny list instead of black list
> >>
> >> Unfortunately we have Master all over our code base, baked into various
> >> APIs and configuration variable names, so for us the necessary changes
> >> amount to a new major release and deprecation cycle. It could well be
> worth
> >> it in the long run. We exist only as long as we draw a willing and
> >> sufficient contributor community. It also wouldn’t be great to have an
> >> activist fork appear somewhere, even if unlikely to be successful.
> >>
> >> Relevant JIRAs are:
> >>
> >> - HBASE-12677 :
> >> Update replication docs to clarify terminology
> >> - HBASE-13852 :
> >> Replace master-slave terminology in book, site, and javadoc with a
> more
> >> modern vocabulary
> >> - HBASE-24576 :
> >> Changing "whitelist" and "blacklist" in our docs and project
> >>
> >> In response to this proposal, a member of the PMC asked if the term
> >> 'master' used by itself would be fine, because we only have use of
> 'slave'
> >> in replication documentation and that is easily addressed. In response
> to
> >> this question, others on the PMC suggested that even if only 'master' is
> >> used, in this context it is still a problem.
> >>
> >> For folks who are surprised or lacking context on the details of this
> >> discussion, one PMC member offered a link to this draft RFC as
> background:
> >> https://tools.ietf.org/id/draft-knodel-terminology-00.html
> >>
> >> There was general support for removing the term "master" / "hmaster"
> from
> >> our code base and using the terms "coordinator" or "leader" instead. In
> the
> >> context of replication, "worker" makes less sense and perhaps
> "destination"
> >> or "follower" would be more appropriate terms.
> >>
> >> One PMC member's thoughts on language and non-native English speakers is
> >> worth including in its entirety:
> >>
> >> While words like blacklist/whitelist/slave clearly have those negative
> >> references, word master might not have the same impact for non native
> >> English speakers like myself where the literal translation to my mother
> >> tongue does not have this same bad connotation. Replacing all references
> >> for word *master *on our docs/codebase is a huge effort, I guess such a
> >> decision would be more suitable for native English speakers folks, and
> >> maybe we should consider the opinion of contributors from that ethinic
> >> minority as well?
> >>
> >> These are good questions for public discussion.
> >>
> >> We have a consensus in the PMC, at this time, that is supportive of
> making
> >> the above discussed terminology changes. However, we also have concerns
> >> about what it would take to accomplish meaningful changes. Several on
> the
> >> PMC offered support in the form of cycles to review pull requests and
> >> patches, and two PMC members offered  personal bandwidth for creating
> and
> >> releasing new code lines as needed to complete a deprecation cycle.
> >>
> >> Unfortunately, the terms "master" and "hmaster" appear throughout our
> code
> >> base in 

Re: [DISCUSS] Removing problematic terms from our project

[Josh Elser]

+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 outweighs the potential
friction they add. They make me personally less enthusiastic about
contributing. That's enough friction for me to advocate removing them.

AFAICT reworking our replication stuff in terms of "active" and "passive"
clusters did not result in a big spike of folks asking new questions about
where authority for state was.

On Mon, Jun 22, 2020, 13:39 Andrew Purtell  wrote:


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 discussion on private@ on June 9, 2020 with an
observation of this activity and this suggestion:

There is a renewed push back against classic technology industry terms that
have negative modern connotations.

In the case of HBase, the following substitutions might be proposed:

- Coordinator instead of master

- Worker instead of slave

Recommendations for these additional substitutions also come up in this
type of discussion:

- Accept list instead of white list

- Deny list instead of black list

Unfortunately we have Master all over our code base, baked into various
APIs and configuration variable names, so for us the necessary changes
amount to a new major release and deprecation cycle. It could well be worth
it in the long run. We exist only as long as we draw a willing and
sufficient contributor community. It also wouldn’t be great to have an
activist fork appear somewhere, even if unlikely to be successful.

Relevant JIRAs are:

- HBASE-12677 :
Update replication docs to clarify terminology
- HBASE-13852 :
Replace master-slave terminology in book, site, and javadoc with a more
modern vocabulary
- HBASE-24576 :
Changing "whitelist" and "blacklist" in our docs and project

In response to this proposal, a member of the PMC asked if the term
'master' used by itself would be fine, because we only have use of 'slave'
in replication documentation and that is easily addressed. In response to
this question, others on the PMC suggested that even if only 'master' is
used, in this context it is still a problem.

For folks who are surprised or lacking context on the details of this
discussion, one PMC member offered a link to this draft RFC as background:
https://tools.ietf.org/id/draft-knodel-terminology-00.html

There was general support for removing the term "master" / "hmaster" from
our code base and using the terms "coordinator" or "leader" instead. In the
context of replication, "worker" makes less sense and perhaps "destination"
or "follower" would be more appropriate terms.

One PMC member's thoughts on language and non-native English speakers is
worth including in its entirety:

While words like blacklist/whitelist/slave clearly have those negative
references, word master might not have the same impact for non native
English speakers like myself where the literal translation to my mother
tongue does not have this same bad connotation. Replacing all references
for word *master *on our docs/codebase is a huge effort, I guess such a
decision would be more suitable for native English speakers folks, and
maybe we should consider the opinion of contributors from that ethinic
minority as well?

These are good questions for public discussion.

We have a consensus in the PMC, at this time, that is supportive of making
the above discussed terminology changes. However, we also have concerns
about what it would take to accomplish meaningful changes. Several on the
PMC offered support in the form of cycles to review pull requests and
patches, and two PMC members offered  personal bandwidth for creating and
releasing new code lines as needed to complete a deprecation cycle.

Unfortunately, the terms "master" and "hmaster" appear throughout our code
base in class names, user facing API subject to our project compatibility
guidelines, and configuration variable names, which are also implicated by
compatibility guidelines given the impact of changes to operators and
operations. The changes being discussed are not backwards compatible
changes and cannot be executed with swiftness while simultaneously
preserving compatibility. There must be a deprecation cycle. First, we must
tag all implicated public API and configuration variables as deprecated,
and release HBase 3 with these deprecations in place. Then, we must
undertake rename and removal as appropriate, and release the 

Re: [DISCUSS] Removing problematic terms from our project

[Nick Dimiduk]

>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 as many people as possible. Regardless of one's personal
opinions on the context that encourages this change, I think it has
benefits for the project and benefits for the community. For me, I think
it's about time, well overdue.

Thanks,
Nick

On Mon, Jun 22, 2020 at 12:18 PM Andrew Purtell 
wrote:

> 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
> (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 proposal
> which
> > is accepted and a proposal which is struck out (black pencil line).
> >
> > So in scientific context these are terminologies used. Terminologies
> become
> > offensive if they are used "in the incorrect context". I don't think
> anyone
> > in HBase or Spark community will have objections if these terminologies
> are
> > used as before. Spark used the term in master/slave in Standalone mode
> if i
> > recall correctly.
> >
> > Changing something for the sake of "now being in the limelight" does not
> > make it right. So I beg to differ on this. Having said that it is indeed
> a
> > sign of a civilised mind to entertain an idea without accepting it so
> > whatever the community wishes.
> >
> > HTH
> >
> >
> >
> >
> > LinkedIn *
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> > <
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> >*
> >
> >
> >
> >
> >
> > *Disclaimer:* Use it at your own risk. Any and all responsibility for any
> > loss, damage or destruction of data or any other property which may arise
> > from relying on this email's technical content is explicitly disclaimed.
> > The author will in no case be liable for any monetary damages arising
> from
> > such loss, damage or destruction.
> >
> >
> >
> >
> >> On Mon, 22 Jun 2020 at 19:39, Andrew Purtell 
> wrote:
> >>
> >> 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 discussion on private@ on June 9, 2020
> with an
> >> observation of this activity and this suggestion:
> >>
> >> There is a renewed push back against classic technology industry terms
> that
> >> have negative modern connotations.
> >>
> >> In the case of HBase, the following substitutions might be proposed:
> >>
> >> - Coordinator instead of master
> >>
> >> - Worker instead of slave
> >>
> >> Recommendations for these additional substitutions also come up in this
> >> type of discussion:
> >>
> >> - Accept list instead of white list
> >>
> >> - Deny list instead of black list
> >>
> >> Unfortunately we have Master all over our code base, baked into various
> >> APIs and configuration variable names, so for us the necessary changes
> >> amount to a new major release and deprecation cycle. It could well be
> worth
> >> it in the long run. We exist only as long as we draw a willing and
> >> sufficient contributor community. It also wouldn’t be great to have an
> >> activist fork appear somewhere, even if unlikely to be successful.
> >>
> >> Relevant JIRAs are:
> >>
> >>   - HBASE-12677 :
> >>   Update replication docs to clarify terminology
> >>   - HBASE-13852 :
> >>   Replace master-slave terminology in book, site, and javadoc with a
> more
> >>   modern vocabulary
> >>   - HBASE-24576 :
> >>   Changing "whitelist" and "blacklist" in our docs and project
> >>
> >> In response to this proposal, a member of the PMC asked if the term
> >> 'master' used by itself would be fine, because we only have use of
> 'slave'
> >> in replication documentation and that is easily addressed. In response
> to
> >> this question, others on the PMC suggested that even if only 'master' is
> >> used, in this context it is still a problem.
> >>
> >> For folks who are surprised or lacking context on the details of this
> >> discussion, one PMC member offered a link to this draft RFC as
> background:
> >> https://tools.ietf.org/id/draft-knodel-terminology-00.html
> >>
> >> There was general support for 

Re: [DISCUSS] Removing problematic terms from our project

[Sean Busbey]

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 make me personally less enthusiastic about
contributing. That's enough friction for me to advocate removing them.

AFAICT reworking our replication stuff in terms of "active" and "passive"
clusters did not result in a big spike of folks asking new questions about
where authority for state was.

On Mon, Jun 22, 2020, 13:39 Andrew Purtell  wrote:

> 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 discussion on private@ on June 9, 2020 with an
> observation of this activity and this suggestion:
>
> There is a renewed push back against classic technology industry terms that
> have negative modern connotations.
>
> In the case of HBase, the following substitutions might be proposed:
>
> - Coordinator instead of master
>
> - Worker instead of slave
>
> Recommendations for these additional substitutions also come up in this
> type of discussion:
>
> - Accept list instead of white list
>
> - Deny list instead of black list
>
> Unfortunately we have Master all over our code base, baked into various
> APIs and configuration variable names, so for us the necessary changes
> amount to a new major release and deprecation cycle. It could well be worth
> it in the long run. We exist only as long as we draw a willing and
> sufficient contributor community. It also wouldn’t be great to have an
> activist fork appear somewhere, even if unlikely to be successful.
>
> Relevant JIRAs are:
>
>- HBASE-12677 :
>Update replication docs to clarify terminology
>- HBASE-13852 :
>Replace master-slave terminology in book, site, and javadoc with a more
>modern vocabulary
>- HBASE-24576 :
>Changing "whitelist" and "blacklist" in our docs and project
>
> In response to this proposal, a member of the PMC asked if the term
> 'master' used by itself would be fine, because we only have use of 'slave'
> in replication documentation and that is easily addressed. In response to
> this question, others on the PMC suggested that even if only 'master' is
> used, in this context it is still a problem.
>
> For folks who are surprised or lacking context on the details of this
> discussion, one PMC member offered a link to this draft RFC as background:
> https://tools.ietf.org/id/draft-knodel-terminology-00.html
>
> There was general support for removing the term "master" / "hmaster" from
> our code base and using the terms "coordinator" or "leader" instead. In the
> context of replication, "worker" makes less sense and perhaps "destination"
> or "follower" would be more appropriate terms.
>
> One PMC member's thoughts on language and non-native English speakers is
> worth including in its entirety:
>
> While words like blacklist/whitelist/slave clearly have those negative
> references, word master might not have the same impact for non native
> English speakers like myself where the literal translation to my mother
> tongue does not have this same bad connotation. Replacing all references
> for word *master *on our docs/codebase is a huge effort, I guess such a
> decision would be more suitable for native English speakers folks, and
> maybe we should consider the opinion of contributors from that ethinic
> minority as well?
>
> These are good questions for public discussion.
>
> We have a consensus in the PMC, at this time, that is supportive of making
> the above discussed terminology changes. However, we also have concerns
> about what it would take to accomplish meaningful changes. Several on the
> PMC offered support in the form of cycles to review pull requests and
> patches, and two PMC members offered  personal bandwidth for creating and
> releasing new code lines as needed to complete a deprecation cycle.
>
> Unfortunately, the terms "master" and "hmaster" appear throughout our code
> base in class names, user facing API subject to our project compatibility
> guidelines, and configuration variable names, which are also implicated by
> compatibility guidelines given the impact of changes to operators and
> operations. The changes being discussed are not backwards compatible
> changes and cannot be executed with swiftness while simultaneously
> preserving compatibility. There must be a deprecation cycle. First, we must
> tag all implicated public API and configuration variables as deprecated,
> and release HBase 3 with these 

Re: [DISCUSS] Removing problematic terms from our project

[Mich Talebzadeh]

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 proposal which
is accepted and a proposal which is struck out (black pencil line).

So in scientific context these are terminologies used. Terminologies become
offensive if they are used "in the incorrect context". I don't think anyone
in HBase or Spark community will have objections if these terminologies are
used as before. Spark used the term in master/slave in Standalone mode if i
recall correctly.

Changing something for the sake of "now being in the limelight" does not
make it right. So I beg to differ on this. Having said that it is indeed a
sign of a civilised mind to entertain an idea without accepting it so
whatever the community wishes.

HTH




LinkedIn * 
https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
*





*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Mon, 22 Jun 2020 at 19:39, Andrew Purtell  wrote:

> 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 discussion on private@ on June 9, 2020 with an
> observation of this activity and this suggestion:
>
> There is a renewed push back against classic technology industry terms that
> have negative modern connotations.
>
> In the case of HBase, the following substitutions might be proposed:
>
> - Coordinator instead of master
>
> - Worker instead of slave
>
> Recommendations for these additional substitutions also come up in this
> type of discussion:
>
> - Accept list instead of white list
>
> - Deny list instead of black list
>
> Unfortunately we have Master all over our code base, baked into various
> APIs and configuration variable names, so for us the necessary changes
> amount to a new major release and deprecation cycle. It could well be worth
> it in the long run. We exist only as long as we draw a willing and
> sufficient contributor community. It also wouldn’t be great to have an
> activist fork appear somewhere, even if unlikely to be successful.
>
> Relevant JIRAs are:
>
>- HBASE-12677 :
>Update replication docs to clarify terminology
>- HBASE-13852 :
>Replace master-slave terminology in book, site, and javadoc with a more
>modern vocabulary
>- HBASE-24576 :
>Changing "whitelist" and "blacklist" in our docs and project
>
> In response to this proposal, a member of the PMC asked if the term
> 'master' used by itself would be fine, because we only have use of 'slave'
> in replication documentation and that is easily addressed. In response to
> this question, others on the PMC suggested that even if only 'master' is
> used, in this context it is still a problem.
>
> For folks who are surprised or lacking context on the details of this
> discussion, one PMC member offered a link to this draft RFC as background:
> https://tools.ietf.org/id/draft-knodel-terminology-00.html
>
> There was general support for removing the term "master" / "hmaster" from
> our code base and using the terms "coordinator" or "leader" instead. In the
> context of replication, "worker" makes less sense and perhaps "destination"
> or "follower" would be more appropriate terms.
>
> One PMC member's thoughts on language and non-native English speakers is
> worth including in its entirety:
>
> While words like blacklist/whitelist/slave clearly have those negative
> references, word master might not have the same impact for non native
> English speakers like myself where the literal translation to my mother
> tongue does not have this same bad connotation. Replacing all references
> for word *master *on our docs/codebase is a huge effort, I guess such a
> decision would be more suitable for native English speakers folks, and
> maybe we should consider the opinion of contributors from that ethinic
> minority as well?
>
> These are good questions for public discussion.
>
> We have a consensus in the PMC, at this time, that is supportive of making
> the above discussed terminology changes. However, we also have concerns
> about what it would take to accomplish 

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

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 (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 proposal which
> is accepted and a proposal which is struck out (black pencil line).
> 
> So in scientific context these are terminologies used. Terminologies become
> offensive if they are used "in the incorrect context". I don't think anyone
> in HBase or Spark community will have objections if these terminologies are
> used as before. Spark used the term in master/slave in Standalone mode if i
> recall correctly.
> 
> Changing something for the sake of "now being in the limelight" does not
> make it right. So I beg to differ on this. Having said that it is indeed a
> sign of a civilised mind to entertain an idea without accepting it so
> whatever the community wishes.
> 
> HTH
> 
> 
> 
> 
> LinkedIn * 
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> *
> 
> 
> 
> 
> 
> *Disclaimer:* Use it at your own risk. Any and all responsibility for any
> loss, damage or destruction of data or any other property which may arise
> from relying on this email's technical content is explicitly disclaimed.
> The author will in no case be liable for any monetary damages arising from
> such loss, damage or destruction.
> 
> 
> 
> 
>> On Mon, 22 Jun 2020 at 19:39, Andrew Purtell  wrote:
>> 
>> 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 discussion on private@ on June 9, 2020 with an
>> observation of this activity and this suggestion:
>> 
>> There is a renewed push back against classic technology industry terms that
>> have negative modern connotations.
>> 
>> In the case of HBase, the following substitutions might be proposed:
>> 
>> - Coordinator instead of master
>> 
>> - Worker instead of slave
>> 
>> Recommendations for these additional substitutions also come up in this
>> type of discussion:
>> 
>> - Accept list instead of white list
>> 
>> - Deny list instead of black list
>> 
>> Unfortunately we have Master all over our code base, baked into various
>> APIs and configuration variable names, so for us the necessary changes
>> amount to a new major release and deprecation cycle. It could well be worth
>> it in the long run. We exist only as long as we draw a willing and
>> sufficient contributor community. It also wouldn’t be great to have an
>> activist fork appear somewhere, even if unlikely to be successful.
>> 
>> Relevant JIRAs are:
>> 
>>   - HBASE-12677 :
>>   Update replication docs to clarify terminology
>>   - HBASE-13852 :
>>   Replace master-slave terminology in book, site, and javadoc with a more
>>   modern vocabulary
>>   - HBASE-24576 :
>>   Changing "whitelist" and "blacklist" in our docs and project
>> 
>> In response to this proposal, a member of the PMC asked if the term
>> 'master' used by itself would be fine, because we only have use of 'slave'
>> in replication documentation and that is easily addressed. In response to
>> this question, others on the PMC suggested that even if only 'master' is
>> used, in this context it is still a problem.
>> 
>> For folks who are surprised or lacking context on the details of this
>> discussion, one PMC member offered a link to this draft RFC as background:
>> https://tools.ietf.org/id/draft-knodel-terminology-00.html
>> 
>> There was general support for removing the term "master" / "hmaster" from
>> our code base and using the terms "coordinator" or "leader" instead. In the
>> context of replication, "worker" makes less sense and perhaps "destination"
>> or "follower" would be more appropriate terms.
>> 
>> One PMC member's thoughts on language and non-native English speakers is
>> worth including in its entirety:
>> 
>> While words like blacklist/whitelist/slave clearly have those negative
>> references, word master might not have the same impact for non native
>> English speakers like myself where the literal translation to my mother
>> tongue does not have this same bad connotation. Replacing all references
>> for word *master *on our docs/codebase is a huge effort, I guess such a
>> decision would be more suitable for native English speakers 

[DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

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 discussion on private@ on June 9, 2020 with an
observation of this activity and this suggestion:

There is a renewed push back against classic technology industry terms that
have negative modern connotations.

In the case of HBase, the following substitutions might be proposed:

- Coordinator instead of master

- Worker instead of slave

Recommendations for these additional substitutions also come up in this
type of discussion:

- Accept list instead of white list

- Deny list instead of black list

Unfortunately we have Master all over our code base, baked into various
APIs and configuration variable names, so for us the necessary changes
amount to a new major release and deprecation cycle. It could well be worth
it in the long run. We exist only as long as we draw a willing and
sufficient contributor community. It also wouldn’t be great to have an
activist fork appear somewhere, even if unlikely to be successful.

Relevant JIRAs are:

   - HBASE-12677 :
   Update replication docs to clarify terminology
   - HBASE-13852 :
   Replace master-slave terminology in book, site, and javadoc with a more
   modern vocabulary
   - HBASE-24576 :
   Changing "whitelist" and "blacklist" in our docs and project

In response to this proposal, a member of the PMC asked if the term
'master' used by itself would be fine, because we only have use of 'slave'
in replication documentation and that is easily addressed. In response to
this question, others on the PMC suggested that even if only 'master' is
used, in this context it is still a problem.

For folks who are surprised or lacking context on the details of this
discussion, one PMC member offered a link to this draft RFC as background:
https://tools.ietf.org/id/draft-knodel-terminology-00.html

There was general support for removing the term "master" / "hmaster" from
our code base and using the terms "coordinator" or "leader" instead. In the
context of replication, "worker" makes less sense and perhaps "destination"
or "follower" would be more appropriate terms.

One PMC member's thoughts on language and non-native English speakers is
worth including in its entirety:

While words like blacklist/whitelist/slave clearly have those negative
references, word master might not have the same impact for non native
English speakers like myself where the literal translation to my mother
tongue does not have this same bad connotation. Replacing all references
for word *master *on our docs/codebase is a huge effort, I guess such a
decision would be more suitable for native English speakers folks, and
maybe we should consider the opinion of contributors from that ethinic
minority as well?

These are good questions for public discussion.

We have a consensus in the PMC, at this time, that is supportive of making
the above discussed terminology changes. However, we also have concerns
about what it would take to accomplish meaningful changes. Several on the
PMC offered support in the form of cycles to review pull requests and
patches, and two PMC members offered  personal bandwidth for creating and
releasing new code lines as needed to complete a deprecation cycle.

Unfortunately, the terms "master" and "hmaster" appear throughout our code
base in class names, user facing API subject to our project compatibility
guidelines, and configuration variable names, which are also implicated by
compatibility guidelines given the impact of changes to operators and
operations. The changes being discussed are not backwards compatible
changes and cannot be executed with swiftness while simultaneously
preserving compatibility. There must be a deprecation cycle. First, we must
tag all implicated public API and configuration variables as deprecated,
and release HBase 3 with these deprecations in place. Then, we must
undertake rename and removal as appropriate, and release the result as
HBase 4.

One PMC member raised a question in this context included here in entirety:

Are we willing to commit to rolling through the major versions at a pace
that's necessary to make this transition as swift as
reasonably possible?

This is a question for all of us. For the PMC, who would supervise the
effort, perhaps contribute to it, and certainly vote on the release
candidates. For contributors and potential contributors, who would provide
the necessary patches. For committers, who would be required to review and
commit the relevant changes.

Although there has been some initial discussion, there is no singular
proposal, or plan, or set of decisions made at this time. Wrestling