-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 <st...@duboce.net>于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 <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.
> >
> > 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 <ndimi...@apache.org>
> wrote:
> >
> > > 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"<user@hbase.apache.org>;
> > > > > 抄送: "dev"<d...@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
> > > >
> > >
> >
>
