[ 
https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009480#comment-14009480
 ] 

Jason Smith commented on COUCHDB-2248:
--------------------------------------

Often, speakers of English as a second language use the literal English words 
in their own technical vocabulary. In the Thai language, in a database or 
software context, "master" and "slave" are transliterated English loanwords. 
(Well, bizarrely their pronunciation for "slave" rhymes with "suave.") If you 
talked about a ทาส/นายทาส ("that/nai-that") database configuration, it would 
sound like a bad attempt to show off your expensive education.

I think this is common phenomenon. Where there is no namespace collision (any 
language except English), you get lots of precision by adopting the foreign 
English word.

Note, I am only providing background information here. I agree that it is a 
term of art which provides clarity; but I am also comfortable with the language 
treadmill, where some words are retired for various reasons.

At Iris Couch, we stopped using this term on technical grounds. It takes work 
to make a master-slave CouchDB cluster, to make a less-important CouchDB node. 
You necessarily need external tooling like a proxy. The normal operational mode 
for CouchDB is reads and writes on each one. So we had "primary" and 
"secondaries" mostly to indicate which couch was to be backed up.

> Replace "master" and "slave" terminology
> ----------------------------------------
>
>                 Key: COUCHDB-2248
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2248
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Documentation
>            Reporter: Noah Slater
>            Priority: Trivial
>
> Inspired by the comments on this PR:
> https://github.com/django/django/pull/2692
> Summary is: `master` and `slave` are racially charged terms, and it would be 
> good to avoid them. Django have gone for `primary` and `replica`. But we also 
> have to deal with what we now call multi-master setups. I propose "peer to 
> peer" as a replacement, or just "peer" if you're describing one node.
> As far as I can tell, the primary work here is the docs. The wiki and any 
> supporting material can be updated after.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to