In mitigation, we should only do the revision if the community feels:
1. There is a need to revise historical context 2. We by virtue of accepting changes will make a better team 3. It will have little or no impact on the current functionality 4. Given that most products in production lag few versions behind, in all likelihood, it may take few years before the changes are materialised 5. If there is a clear majority message that we ought to change, then a sensible roadmap should be prepared with timelines. 6. We should not change the things because it is fashionable. Those who have visited Linkedlin recently would have noticed that there are a lot of companies who rightly or wrongly have come out with the support of the current trends and equally have attracted a lot of criticism by quote "not being sincere" I know I am not making myself popular but I think we ought to weigh things up in true context. HTH LinkedIn * https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* *Disclaimer:* Use it at your own risk. Any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on this email's technical content is explicitly disclaimed. The author will in no case be liable for any monetary damages arising from such loss, damage or destruction. On Mon, 22 Jun 2020 at 20:14, Mich Talebzadeh <mich.talebza...@gmail.com> wrote: > > Hi, > > Thank you for the proposals. > > I am afraid I have to agree to differ. The term master and slave (commonly > used in Big data tools (not confined to HBase only) is BAU and historical) > and bears no resemblance to anything recent. > > Additionally, both whitelist and blacklist simply refer to a > proposal which is accepted and a proposal which is struck out (black > pencil line). > > So in scientific context these are terminologies used. Terminologies > become offensive if they are used "in the incorrect context". I don't think > anyone in HBase or Spark community will have objections if these > terminologies are used as before. Spark used the term in master/slave in > Standalone mode if i recall correctly. > > Changing something for the sake of "now being in the limelight" does not > make it right. So I beg to differ on this. Having said that it is indeed a > sign of a civilised mind to entertain an idea without accepting it so > whatever the community wishes. > > HTH > > > > > LinkedIn * > https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw > <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* > > > > > > *Disclaimer:* Use it at your own risk. Any and all responsibility for any > loss, damage or destruction of data or any other property which may arise > from relying on this email's technical content is explicitly disclaimed. > The author will in no case be liable for any monetary damages arising from > such loss, damage or destruction. > > > > > On Mon, 22 Jun 2020 at 19: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@. >> >
