On Tue, Jun 23, 2020 at 13:11 Sean Busbey <bus...@apache.org> 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"<apurt...@apache.org>;
> > 发送时间: 2020年6月23日(星期二) 凌晨5:24
> > 收件人: "Hbase-User"<u...@hbase.apache.org>;
> > 抄送: "dev"<dev@hbase.apache.org>;
> > 主题: 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,
> > > 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
> > > <rushabh.s...@salesforce.com.invalid> 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 <els...@apache.org
> >
> > 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 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
> > > > > >> 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 motivation for
> > compatibility) is a
> > > task
> > > > > for
> > > > > >> all of us to undertake (or not) in public on dev@
> > and user@.
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> > - A23, Crosstalk
>
