Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#22707 closed Cleanup/optimization (wontfix)

Database-related terminology in docs is misleading

Reported by: Meira Owned by: nobody
Component: Documentation Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

All occurences of "master/slave" were recently replaced with "leader/follower" (https://github.com/django/django/pull/2692), then with "primary/replica" (https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1).
This new terminology is vague, ill-advised, and very misleading.

Django is a server-side framework with the goal of making Pythonistas' life sweet. By no means this requires reforming old and widely accepted database terminology, or feeding fat internet trolls like Feminist Software Foundation.

Let's look at the famous Zen of Python:

  • Special cases aren't special enough to break the rules.
  • Although practicality beats purity.
  • There should be one-- and preferably only one --obvious way to do it.

And, above all:

  • Explicit is better than implicit.

Here are four reasons, baked in the core of the language, as well as in the core or the developers' hearts, for why changing this clear, concise and immediately recognized terminology is a bad idea.

This terminology has been used for a long time, and by no means those purely technical terms carry racially charged meanings to users, neither are they offending in any other way.
This patch replaces all occurrences of "primary/replica" with the good old "master/slave" together with now unnecessary comments like "referred to as master/slave by some databases".

Change History (5)

comment:2 by Daniele Procida, 10 years ago

Thanks for your comments, and your pull request.

You may be right. Or you may be wrong.

It's clearly an issue that seems to mean a lot to a lot of people. It's not one that can be satisfactorily resolved in Trac or GitHub issues.

Whatever we do about this, we're not going to do it on the basis of whatever latest pull request that has come in.

For now, we're going to leave it as master/replica. Time will tell whether that's the best solution. If it still seems glaringly wrong to you in six months' time, say, feel free to raise it again, but in the meantime, please accept that it's going to stay like that for the time being.

comment:3 by Daniele Procida, 10 years ago

Resolution: wontfix
Status: newclosed

comment:4 by anonymous, 10 years ago

Ok, then, why the first commit with that change was merged, instead of telling the author to wait 6 months?

comment:5 by Noah Slater <nslater@…>, 10 years ago

Sean B. Palmer did some research on this topic for CouchDB after I opened a similar bug on that project.

https://issues.apache.org/jira/browse/COUCHDB-2248?focusedCommentId=14009743#comment-14009743

He argues that master/slave was originally used to refer to hardware that controls other hardware. It has since been borrowed for databases, but doesn't make conceptual sense as databases are in the business of copying data, not controlling the behaviour of each other.

There is a separate sense of the word master meaning the primary copy of something. We use this sense when we talk about master recordings. The two senses seem to have been confused with each other. When we speak about master databases, we're talking about master records. And so replica, copy, or clone are obvious parings.

I thought this was interesting because I am in favour of retiring words that a discriminatory or offensive to people, regardless of how logical it is. But this is a clear argument that supports the change while also neatly explaining why talking about master branches in Git and so on is fine.

Note: See TracTickets for help on using tickets.
Back to Top