REQUEST: Replace/Remove the terms "slave/master" and "blacklist/whitelist"

Functionality

Replace/Remove all references to racially-charged jargon for neutral and inclusive terminology.

OpenFOAM should join the contemporary efforts of various tech companies and open-source projects in this regard, such as (the most recent) Linux (kernel), GitHub, RedHat, Android etc.

Proposed alternatives:

For master/slave:

primary/secondary
main/replica or subordinate
initiator/target
requester/responder
controller/device
host/worker or proxy
leader/follower
director/performer

For blacklist/whitelist:

denylist/allowlist
blocklist/passlist

added feature feature request labels

changed title from FEATURE-REQUEST: Replace/Remove the terms "slave/master" and "blacklist/whitelist" to REQUEST: Replace/Remove the terms "slave/master" and "blacklist/whitelist"

made the issue confidential

Perhaps not a simple black/white distinction, but more of a grey area?

• Pstream::master() --> Pstream::leader() ??

1e95af4d

• Patrician/plebeian are both longer.
• Lord/serf is shorter.

Honestly, I would pick something among the proposed alternatives from the Linux kernel, if to proceed. Serfdom is as bad as slavery in my opinion.

Please feel free to close the ticket, if need be. We don't need to proceed in it, anyways.

FYI, GitHub replaces master with main from 1st Oct 20: https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/

GitLab will likely follow it.

My current tendency is towards master/worker or leader/worker. Replacing master with main in github/gitlab actually seems quite reasonable to me - ie, it is the main branch, whereas master could imply that the others are copies (cf, master key, digital master etc). However, Pstream::main() doesn't really work for me.

Yes yes, I agree with you. I have just wanted to highlight a development which may affect us before v2012. :)

Don't see the relation between master/slave and black/white. It is the meaning you put into it or the assumption of meaning black/white. For me master/slave does not have nothing to do with racism.

It seems that I need to press on the argument. :)

Due to the events associated with George Floyd in the USA, many tech companies have recently (and rightfully) became sensitive to the ways in which specific pieces of terminology — which at one time were/are common and standard in a given technological context — can themselves be offensive and hurtful to different minority groups.

It is not about how we perceive the terminology. The zeitgeist indicates that there are people who are and/or may be hurt by them, and who are and/or may be made to feel unwelcome by their use due not to technical reasons but to their historical and social context. That’s simply enough reason to replace them in my humble opinion.

Currently, there are numerous programming teams that have been determined to replace terms such as “blacklist” and “whitelist” within their respective codebases.‘Blacklist’ and ‘whitelist’, I think, reinforce the notion that black==bad and white==good. These terms can be replaced by ‘blocklist’ and ‘allowlist’ without changing their meanings, but particular instances may need other replacements.

Various programming pioneers suggested that the entire software industry make a collective decision to voluntarily stop using master/slave terminology in software. While the heads of large companies could certainly issue a top-down order preventing the use of those terms, it might prove more difficult to convince independent developers and smaller projects to shift quickly, at least until new terminology is widely adopted. This is a topic therefore that many developers, including us, will only continue to debate for quite some time to come.

Admittedly, there is always work to be done in this area. Though removing and adjusting such offensive terminology is itself not an ultimate solution, and should not be used as a replacement for more meaningful actions taken to show solidarity with marginalized groups, this does not mean that this is not a meaningful act unto itself.

Lastly, the entry was a mere suggestion for a discussion, not an arrogant request. I havent seen yet anybody supported this argument in our team, and this suggests I also need to see things from your perspective. I know nobody is racist here AT ALL, but we have been doing discussions, and increasing our awareness.

And if the request is not wholly accepted and implemented, that's perfecly fine. :) I will still love you. :)

We can remove whitelist/blacklist from the discussion. Starting from Kuti's original remarks, I re-examined the code. Especially since I wasn't entirely convinced about the terminology in the first place. In this case whitelist/blacklist makes perfect sense for techies, but may not otherwise be very descriptive. Additionally, what if the "lists" are only accepting/blocking a single item (not a list)?

I decided that using allow/deny fits better as a generic description of what they are doing, are not necessarily "lists" per se. For techies, they are also familiar enough from places like /etc/hosts.allow and /etc/hosts.deny.

In merge-request !382 (merged) added in Pstream::allProcs() and Pstream::subProcs() methods which make iterating across the ranks easier. As a byproduct, also removes need for firstSlave and lastSlave methods (but left for compatibility).

As indicated in commits e18ff114, 5dc5ea92, can now directly iterate.

for (const int proci : Pstream::allProcs()) { ... }

for (const int proci : Pstream::subProcs()) { ... }

Deferred changing occurrences of master/slave for now.

closed

Still retaining master in most places.

That's ok. Thanks for changing some of the stuff there.

made the issue visible to everyone