hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: [DISCUSS] Removing problematic terms from our project
Date Tue, 23 Jun 2020 20:10:48 GMT
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 <18031031@qq.com> wrote:

> IMO, master is ok if not used with slave together.
>
>
> -1/+1/+1/+1
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人:&nbsp;"Andrew Purtell"<apurtell@apache.org&gt;;
> 发送时间:&nbsp;2020年6月23日(星期二) 凌晨5:24
> 收件人:&nbsp;"Hbase-User"<user@hbase.apache.org&gt;;
> 抄送:&nbsp;"dev"<dev@hbase.apache.org&gt;;
> 主题:&nbsp;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 <gjacoby@apache.org&gt;
> wrote:
>
> &gt; For most of the proposals (slave -&gt; worker, blacklist -&gt;
> denylist,
> &gt; whitelist-&gt; allowlist), I'm +1 (nonbinding). Denylist and
> acceptlist even
> &gt; have the advantage of being clearer than the terms they're replacing.
> &gt;
> &gt; However, I'm not convinced about changing "master" to "coordinator",
> or
> &gt; something similar. Unlike "slave", which is negative in any context,
> &gt; "master" has many definitions, including some common ones which do not
> &gt; appear problematic. See
> https://www.merriam-webster.com/dictionary/master
> &gt <https://www.merriam-webster.com/dictionary/master&gt>; for
> &gt; examples. In particular, the progression of an artisan was from
> &gt; "apprentice" to "journeyman" to "master". A master smith, carpenter,
> or
> &gt; artist would run a shop managing lots of workers and apprentices who
> would
> &gt; hope to become masters of their own someday. So "master" and "worker"
> can
> &gt; still go together.
> &gt;
> &gt; Since it's the least problematic term, and by far the hardest term to
> &gt; change (both within HBase and with effects on downstream projects
> such as
> &gt; Ambari), I'm -0 (nonbinding) on changing "master".
> &gt;
> &gt; Geoffrey
> &gt;
> &gt; On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
> &gt; <rushabh.shah@salesforce.com.invalid&gt; wrote:
> &gt;
> &gt; &gt; +1 to renaming.
> &gt; &gt;
> &gt; &gt;
> &gt; &gt; Rushabh Shah
> &gt; &gt;
> &gt; &gt;&nbsp;&nbsp;&nbsp; - Software Engineering SMTS | Salesforce
> &gt; &gt;&nbsp;&nbsp;&nbsp; -
> &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Mobile:
213 422 9052
> &gt; &gt;
> &gt; &gt;
> &gt; &gt;
> &gt; &gt; On Mon, Jun 22, 2020 at 1:18 PM Josh Elser <elserj@apache.org&gt;
> wrote:
> &gt; &gt;
> &gt; &gt; &gt; +1
> &gt; &gt; &gt;
> &gt; &gt; &gt; On 6/22/20 4:03 PM, Sean Busbey wrote:
> &gt; &gt; &gt; &gt; We should change our use of these terms. We can be
> equally or more
> &gt; &gt; clear
> &gt; &gt; &gt; in
> &gt; &gt; &gt; &gt; what we are trying to convey where they are present.
> &gt; &gt; &gt; &gt;
> &gt; &gt; &gt; &gt; That they have been used historically is only useful
> if the advantage
> &gt; &gt; we
> &gt; &gt; &gt; &gt; gain from using them through that shared context
> outweighs the
> &gt; &gt; potential
> &gt; &gt; &gt; &gt; friction they add. They make me personally less
> enthusiastic about
> &gt; &gt; &gt; &gt; contributing. That's enough friction for me to
> advocate removing
> &gt; them.
> &gt; &gt; &gt; &gt;
> &gt; &gt; &gt; &gt; AFAICT reworking our replication stuff in terms of
> "active" and
> &gt; &gt; "passive"
> &gt; &gt; &gt; &gt; clusters did not result in a big spike of folks asking
> new questions
> &gt; &gt; &gt; about
> &gt; &gt; &gt; &gt; where authority for state was.
> &gt; &gt; &gt; &gt;
> &gt; &gt; &gt; &gt; On Mon, Jun 22, 2020, 13:39 Andrew Purtell <
> apurtell@apache.org&gt;
> &gt; &gt; wrote:
> &gt; &gt; &gt; &gt;
> &gt; &gt; &gt; &gt;&gt; In response to renewed attention at the Foundation
> toward addressing
> &gt; &gt; &gt; &gt;&gt; culturally problematic language and terms
often
> used in technical
> &gt; &gt; &gt; &gt;&gt; documentation and discussion, several projects
> have begun
> &gt; discussions,
> &gt; &gt; &gt; or
> &gt; &gt; &gt; &gt;&gt; made proposals, or started work along these
lines.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; The HBase PMC began its own discussion on
private@
> on June 9, 2020
> &gt; &gt; &gt; with an
> &gt; &gt; &gt; &gt;&gt; observation of this activity and this suggestion:
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; There is a renewed push back against classic
> technology industry
> &gt; terms
> &gt; &gt; &gt; that
> &gt; &gt; &gt; &gt;&gt; have negative modern connotations.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; In the case of HBase, the following substitutions
> might be proposed:
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; - Coordinator instead of master
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; - Worker instead of slave
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; Recommendations for these additional substitutions
> also come up in
> &gt; &gt; this
> &gt; &gt; &gt; &gt;&gt; type of discussion:
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; - Accept list instead of white list
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; - Deny list instead of black list
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; Unfortunately we have Master all over our
code
> base, baked into
> &gt; &gt; various
> &gt; &gt; &gt; &gt;&gt; APIs and configuration variable names, so
for us
> the necessary
> &gt; changes
> &gt; &gt; &gt; &gt;&gt; amount to a new major release and deprecation
> cycle. It could well
> &gt; be
> &gt; &gt; &gt; worth
> &gt; &gt; &gt; &gt;&gt; it in the long run. We exist only as long
as we
> draw a willing and
> &gt; &gt; &gt; &gt;&gt; sufficient contributor community. It also
wouldn’t
> be great to have
> &gt; an
> &gt; &gt; &gt; &gt;&gt; activist fork appear somewhere, even if unlikely
> to be successful.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; Relevant JIRAs are:
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; -
HBASE-12677 <
> &gt; https://issues.apache.org/jira/browse/HBASE-12677
> &gt; &gt; &gt;:
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Update
replication docs to
> clarify terminology
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; -
HBASE-13852 <
> &gt; https://issues.apache.org/jira/browse/HBASE-13852
> &gt; &gt; &gt;:
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Replace
master-slave
> terminology in book, site, and javadoc
> &gt; with a
> &gt; &gt; &gt; more
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; modern
vocabulary
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; -
HBASE-24576 <
> &gt; https://issues.apache.org/jira/browse/HBASE-24576
> &gt; &gt; &gt;:
> &gt; &gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Changing
"whitelist" and
> "blacklist" in our docs and project
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; In response to this proposal, a member of
the PMC
> asked if the term
> &gt; &gt; &gt; &gt;&gt; 'master' used by itself would be fine, because
we
> only have use of
> &gt; &gt; &gt; 'slave'
> &gt; &gt; &gt; &gt;&gt; in replication documentation and that is
easily
> addressed. In
> &gt; response
> &gt; &gt; &gt; to
> &gt; &gt; &gt; &gt;&gt; this question, others on the PMC suggested
that
> even if only
> &gt; 'master'
> &gt; &gt; is
> &gt; &gt; &gt; &gt;&gt; used, in this context it is still a problem.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; For folks who are surprised or lacking context
on
> the details of
> &gt; this
> &gt; &gt; &gt; &gt;&gt; discussion, one PMC member offered a link
to this
> draft RFC as
> &gt; &gt; &gt; background:
> &gt; &gt; &gt; &gt;&gt;
> https://tools.ietf.org/id/draft-knodel-terminology-00.html
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; There was general support for removing the
term
> "master" / "hmaster"
> &gt; &gt; &gt; from
> &gt; &gt; &gt; &gt;&gt; our code base and using the terms "coordinator"
or
> "leader" instead.
> &gt; &gt; In
> &gt; &gt; &gt; the
> &gt; &gt; &gt; &gt;&gt; context of replication, "worker" makes less
sense
> and perhaps
> &gt; &gt; &gt; "destination"
> &gt; &gt; &gt; &gt;&gt; or "follower" would be more appropriate terms.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; One PMC member's thoughts on language and
> non-native English
> &gt; speakers
> &gt; &gt; is
> &gt; &gt; &gt; &gt;&gt; worth including in its entirety:
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; While words like blacklist/whitelist/slave
clearly
> have those
> &gt; negative
> &gt; &gt; &gt; &gt;&gt; references, word master might not have the
same
> impact for non
> &gt; native
> &gt; &gt; &gt; &gt;&gt; English speakers like myself where the literal
> translation to my
> &gt; &gt; mother
> &gt; &gt; &gt; &gt;&gt; tongue does not have this same bad connotation.
> Replacing all
> &gt; &gt; references
> &gt; &gt; &gt; &gt;&gt; for word *master *on our docs/codebase is
a huge
> effort, I guess
> &gt; such
> &gt; &gt; a
> &gt; &gt; &gt; &gt;&gt; decision would be more suitable for native
English
> speakers folks,
> &gt; and
> &gt; &gt; &gt; &gt;&gt; maybe we should consider the opinion of
> contributors from that
> &gt; ethinic
> &gt; &gt; &gt; &gt;&gt; minority as well?
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; These are good questions for public discussion.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; We have a consensus in the PMC, at this time,
that
> is supportive of
> &gt; &gt; &gt; making
> &gt; &gt; &gt; &gt;&gt; the above discussed terminology changes.
However,
> we also have
> &gt; &gt; concerns
> &gt; &gt; &gt; &gt;&gt; about what it would take to accomplish meaningful
> changes. Several
> &gt; on
> &gt; &gt; &gt; the
> &gt; &gt; &gt; &gt;&gt; PMC offered support in the form of cycles
to
> review pull requests
> &gt; and
> &gt; &gt; &gt; &gt;&gt; patches, and two PMC members offered&nbsp;
> personal bandwidth for
> &gt; creating
> &gt; &gt; &gt; and
> &gt; &gt; &gt; &gt;&gt; releasing new code lines as needed to complete
a
> deprecation cycle.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; Unfortunately, the terms "master" and "hmaster"
> appear throughout
> &gt; our
> &gt; &gt; &gt; code
> &gt; &gt; &gt; &gt;&gt; base in class names, user facing API subject
to
> our project
> &gt; &gt; &gt; compatibility
> &gt; &gt; &gt; &gt;&gt; guidelines, and configuration variable names,
> which are also
> &gt; &gt; implicated
> &gt; &gt; &gt; by
> &gt; &gt; &gt; &gt;&gt; compatibility guidelines given the impact
of
> changes to operators
> &gt; and
> &gt; &gt; &gt; &gt;&gt; operations. The changes being discussed are
not
> backwards compatible
> &gt; &gt; &gt; &gt;&gt; changes and cannot be executed with swiftness
> while simultaneously
> &gt; &gt; &gt; &gt;&gt; preserving compatibility. There must be a
> deprecation cycle. First,
> &gt; we
> &gt; &gt; &gt; must
> &gt; &gt; &gt; &gt;&gt; tag all implicated public API and configuration
> variables as
> &gt; &gt; deprecated,
> &gt; &gt; &gt; &gt;&gt; and release HBase 3 with these deprecations
in
> place. Then, we must
> &gt; &gt; &gt; &gt;&gt; undertake rename and removal as appropriate,
and
> release the result
> &gt; as
> &gt; &gt; &gt; &gt;&gt; HBase 4.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; One PMC member raised a question in this
context
> included here in
> &gt; &gt; &gt; entirety:
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; Are we willing to commit to rolling through
the
> major versions at a
> &gt; &gt; pace
> &gt; &gt; &gt; &gt;&gt; that's necessary to make this transition
as swift
> as
> &gt; &gt; &gt; &gt;&gt; reasonably possible?
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; This is a question for all of us. For the
PMC, who
> would supervise
> &gt; the
> &gt; &gt; &gt; &gt;&gt; effort, perhaps contribute to it, and certainly
> vote on the release
> &gt; &gt; &gt; &gt;&gt; candidates. For contributors and potential
> contributors, who would
> &gt; &gt; &gt; provide
> &gt; &gt; &gt; &gt;&gt; the necessary patches. For committers, who
would
> be required to
> &gt; review
> &gt; &gt; &gt; and
> &gt; &gt; &gt; &gt;&gt; commit the relevant changes.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;&gt; Although there has been some initial discussion,
> there is no
> &gt; singular
> &gt; &gt; &gt; &gt;&gt; proposal, or plan, or set of decisions made
at
> this time. Wrestling
> &gt; &gt; with
> &gt; &gt; &gt; &gt;&gt; this concern and the competing concerns involved
> with addressing it
> &gt; &gt; &gt; &gt;&gt; (motivation for change versus motivation
for
> compatibility) is a
> &gt; task
> &gt; &gt; &gt; for
> &gt; &gt; &gt; &gt;&gt; all of us to undertake (or not) in public
on dev@
> and user@.
> &gt; &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; &gt;
> &gt; &gt; &gt;
> &gt; &gt;
> &gt;
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> &nbsp;&nbsp; - A23, Crosstalk

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message