From dev-return-80005-archive-asf-public=cust-asf.ponee.io@hbase.apache.org Fri Jun 26 17:16:50 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 33E42180656 for ; Fri, 26 Jun 2020 19:16:50 +0200 (CEST) Received: (qmail 8576 invoked by uid 500); 26 Jun 2020 17:16:49 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Delivered-To: moderator for dev@hbase.apache.org Received: (qmail 99247 invoked by uid 99); 25 Jun 2020 23:46:26 -0000 X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=arista.com Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.167.195; helo=mail-oi1-f195.google.com; envelope-from=andrey.elenskiy@arista.com; receiver= X-ASF-DKIM-Sig: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0FinCcZ9+oqK9A7tTccXpKoGFs/qYSHO+94zzzRjtkw=; b=Gw/E/IZnfPq4uwnqRaw1XU0AWkL3E28XTgOJZY68TPHaf1UVBCdaIUx1tclzYK8xPr EblLanHNL7P6I9Qk+YDuCs3JQzskt9zoMRw8TUlZBnngMV7HED+lxm2x4O/95Pg7wjpV QiCl6bJ1iJqsAgk4CNSkdyB7F6+rB9YypWsvTX7td6VkNKv/W8+7tn5/JYl2hiRyigcC FUMASKqIE4+g0phFJ82JtvGNmRhtL11d0ZYoJ70+bXAv2OCKd73eigLcECb5yrx6LP0O lZdy0QXWYGCg50z/1gAN00Y6J7QS5ZVxYinb4x8auxinbboaJHdDhmrC7Sx4b7OfF2r8 Tb4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0FinCcZ9+oqK9A7tTccXpKoGFs/qYSHO+94zzzRjtkw=; b=hTfAOU/IoThAW99eiqu9uQaHE8/5GBFjnl7aXB405bTAIZstnqsEIacjx11qQOMqRA gjum4O6OOtmy/Hkox2gIHfBWYuR7xyaLCKYmvgo3rZS2lMQOtYdUGeAQzpjB9TzCZUmR OkATgDKqKDPA3CG8QBkP0Hiw3cOoro6M1jl14tlNrG8DUhO1YqSBF8kJOw5oGLZI9qMM NFfYaeq18WCk8sEO+jWM1uh23X6CQfwyvmFs4FXpVWtmvnPjirXYGmMfyH7G+U1E4ceG 6Py69BfudPpy627kBOnq8BPl8WdRk4SF8hRKmLzjVi3vah8bxUWUV4HgdqCDT+ug5hFq Gkrw== X-Gm-Message-State: AOAM533Kgn3l7FQ74emO0+plZ77VzVXzmmy3UXkS1A3ngramkhuMbc6I 7T9TlPcUJVczIquENUOudUvz00kqna4xha1v2oyZ+O37Qf/cQQ== X-Google-Smtp-Source: ABdhPJyOpgrL//0UYxtv3Hz/uICBF74nXAhOC8CRsKrxyrtpKkHKFW3DY/4/CC2OGhfYnn7csl0SWcxMc6vF+X8fPyc= X-Received: by 2002:aca:c5c2:: with SMTP id v185mr412545oif.75.1593128779778; Thu, 25 Jun 2020 16:46:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Elenskiy Date: Thu, 25 Jun 2020 16:46:08 -0700 Message-ID: Subject: Re: [DISCUSS] Removing problematic terms from our project To: user@hbase.apache.org Cc: dev Content-Type: multipart/alternative; boundary="00000000000000461e05a8f13372" --00000000000000461e05a8f13372 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is there a word that's not "master" and not "coordinator" that is clear and suitable for (diverse, polyglot) community? There are also: - captain (sounds pretty close to "master" without the negative side and it should be relatable around the world) - conductor (as in orchestra) - controller (in kafka controller assigns partitions) - RegionDriver (more relevant to what it's actually doing in hbase and borrowed from PlacementDrive of TiKV) - AdminServer (as you already have AdminClient to talk to it). On Thu, Jun 25, 2020 at 3:49 PM Sean Busbey wrote: > How about "manager"? > > (It would help me if folks could explain what is lacking in "coordinator"= .) > > On Thu, Jun 25, 2020, 13:32 Nick Dimiduk wrote: > > > On Wed, Jun 24, 2020 at 10:14 PM =E5=BC=A0=E9=93=8E(Duo Zhang) > > wrote: > > > > > -0/+1/+1/+1 > > > > > > I=E2=80=99m the one who asked whether =E2=80=98master=E2=80=99 is saf= e to use without =E2=80=98slave=E2=80=99 > in > > > the private list. > > > > > > I=E2=80=99m still not convinced that it is really necessary and I do = not think > > > other words like =E2=80=98coordinator=E2=80=99 can fully describe the= role of HMaster > in > > > HBase. HBase is more than 10 years old. In the context of HBase, the > word > > > =E2=80=98HMaster=E2=80=99 has its own meaning. Changing the name will= hurt our users > and > > > make them confusing, especially for us non native English speakers... > > > > > > > Is there a word that's not "master" and not "coordinator" that is clear > and > > suitable for (diverse, polyglot) community? > > > > Stack =E4=BA=8E2020=E5=B9=B46=E6=9C=8825=E6=97=A5 =E5= =91=A8=E5=9B=9B06:34=E5=86=99=E9=81=93=EF=BC=9A > > > > > > > +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 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 fil= e > > 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 > > > > wrote: > > > > > > > > > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey > > wrote: > > > > > > > > > > > > > I would like to make sure I am emphatically clear that "maste= r" > > 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 clearl= y > > > such a > > > > > > > context. > > > > > > > > > > > > > > > > > > I agree: to me =E2=80=9CMaster=E2=80=9D, as in =E2=80=9CHMaster= =E2=80=9D caries with it the > > > > master/slave > > > > > > baggage. As an alternative, I prefer the term =E2=80=9Ccoordina= tor=E2=80=9D over > > > > > =E2=80=9Cleader=E2=80=9D. > > > > > > Thus we would have daemons called =E2=80=9Ccoordinator=E2=80=9D= and =E2=80=9Cregion > > server=E2=80=9D. > > > > > > > > > > > > To me, =E2=80=9Cmaster=E2=80=9D as in =E2=80=9Cmaster branch=E2= =80=9D does not carry the same > > > baggage, > > > > > but > > > > > > I=E2=80=99m also in favor changing the name of our default bran= ch 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 maki= ng > > > > *some* > > > > > > > changes. I haven't seen a strong push for "break everything i= n > > the > > > > name > > > > > > of > > > > > > > expediency" (I would personally be fine with this). So barrin= g > > > > > 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 P= R > 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 > > > > > > > > > > > > > > > > > > > > > > > > ------------------ =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB= =B6 ------------------ > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: "Andrew Purtell" > > > > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B46= =E6=9C=8823=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) =E5=87=8C=E6=99=A85:24 > > > > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: "Hbase-User" > > > > > > > =E6=8A=84=E9=80=81: "dev" > > > > > > > =E4=B8=BB=E9=A2=98: 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 wit= h > 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 on= e > > > > 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 cro= ss > > > > 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 > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > For most of the proposals (slave -> worker, blackli= st > > > -> > > > > > > > > denylist, > > > > > > > > > whitelist-> allowlist), I'm +1 (nonbinding). Denyli= st > > 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 i= n > > 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 "maste= r" > > 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 downstre= am > > > > > 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 < > > > > > > elserj@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 i= s > > only > > > > > > useful > > > > > > > > if the advantage > > > > > > > > > > we > > > > > > > > > > > > gain from using them through that share= d > > > > context > > > > > > > > outweighs the > > > > > > > > > > potential > > > > > > > > > > > > friction they add. They make me > personally > > > less > > > > > > > > enthusiastic about > > > > > > > > > > > > contributing. That's enough friction fo= r > 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 > > < > > > > > > > > apurtell@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, sever= al > > > > > projects > > > > > > > > have begun > > > > > > > > > discussions, > > > > > > > > > > > or > > > > > > > > > > > >> made proposals, or started work alo= ng > > > these > > > > > > > lines. > > > > > > > > > > > >> > > > > > > > > > > > >> The HBase PMC began its own > discussion > > on > > > > > > > private@ > > > > > > > > on June 9, 2020 > > > > > > > > > > > with an > > > > > > > > > > > >> observation of this activity and th= is > > > > > > suggestion: > > > > > > > > > > > >> > > > > > > > > > > > >> There is a renewed push back agains= t > > > > 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 additiona= l > > > > > > > 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 ov= er > > 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 a= s > > long > > > > as > > > > > we > > > > > > > > draw a willing and > > > > > > > > > > > >> sufficient contributor community. I= t > > also > > > > > > > wouldn=E2=80=99t > > > > > > > > be great to have > > > > > > > > > an > > > > > > > > > > > >> activist fork appear somewhere, eve= n > 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 th= at > > 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 langua= ge > > 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 opinio= n > 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" a= nd > > > > > "hmaster" > > > > > > > > appear throughout > > > > > > > > > our > > > > > > > > > > > code > > > > > > > > > > > >> base in class names, user facing AP= I > > > > 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 mus= t > > 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. F= or > > the > > > > > PMC, > > > > > > > who > > > > > > > > would supervise > > > > > > > > > the > > > > > > > > > > > >> effort, perhaps contribute to it, a= nd > > > > > 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 initia= l > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > --00000000000000461e05a8f13372--