Re: [DISCUSS] Removing problematic terms from our project
+0/+1/+1/+1 (non-binding)
+0 on replacing `master` 1) because I don't have a strong opinion with any
terms.
-Stephen
On Tue, Jun 23, 2020 at 1:26 PM Andrew Purtell wrote:
> If we were going to do this such that replacements for "master" land in
> HBase 4, then we should commit to doing it by 2021. That gives us
> approximately six months. Contributors who feel this is a priority can do
> the work on trunk and everyone else can continue as they like, with the
> understanding they may have higher than average work at each rebase. There
> would be a stabilization effort on trunk (yeah...) to prepare for an HBase
> 3 release with all necessary deprecations in place. That would be the bulk
> of the time. Immediately after cutting HBase 3 we could make the
> substitutions and release HBase 4 with no other changes. If we do it this
> way the release of HBase 4 would follow 3 but at most a few weeks. There is
> no reason to think we need much of 2021 for this, never mind 2022.
>
>
>
> On Tue, Jun 23, 2020 at 1:11 PM 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.
> >
> > 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
> > >
> > > -
Re: [DISCUSS] Removing problematic terms from our project
If we were going to do this such that replacements for "master" land in
HBase 4, then we should commit to doing it by 2021. That gives us
approximately six months. Contributors who feel this is a priority can do
the work on trunk and everyone else can continue as they like, with the
understanding they may have higher than average work at each rebase. There
would be a stabilization effort on trunk (yeah...) to prepare for an HBase
3 release with all necessary deprecations in place. That would be the bulk
of the time. Immediately after cutting HBase 3 we could make the
substitutions and release HBase 4 with no other changes. If we do it this
way the release of HBase 4 would follow 3 but at most a few weeks. There is
no reason to think we need much of 2021 for this, never mind 2022.
On Tue, Jun 23, 2020 at 1:11 PM 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.
>
> 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
Re: [DISCUSS] Removing problematic terms from our project
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
> ; 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 for state was.
>
> On Mon, Jun 22, 2020, 13:39 Andrew Purtell <
> apurt...@apache.org
> 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
?????? [DISCUSS] Removing problematic terms from our project
IMO, master is ok if not used with slave together. -1/+1/+1/+1 ---- ??:"Andrew Purtell"https://www.merriam-webster.com/dictionary/master for examples. In particular, the progression of an artisan was from "apprentice" to "journeyman" to "master". 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 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 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 with this concern and the competing concerns involved with addressing it (motivation for change versus
