+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 <apurt...@apache.org> 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 <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.
> >
> > 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
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
