Re: [DISCUSS] Removing problematic terms from our project

2020-06-24 Thread 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 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 of the proposals (slave - worker, blacklist -
> > > > > denylist,
> > > > 

Re: [DISCUSS] Removing problematic terms from our project

2020-06-24 Thread 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.
> > > >
> > > >
> > > >
> > > > 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 

Re: [DISCUSS] Removing problematic terms from our project

2020-06-24 Thread 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 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 

Re: [DISCUSS] Removing problematic terms from our project

2020-06-24 Thread 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
> >  ; 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