Misc #17828
closedDeprecate use of master and slave
Description
In light of organizations like Basecamp and GitHub refraining from using words like "master" and "slave," it may be a good time for Ruby Core team to follow the practices. I also feel that this issue has been discussed before, and there may already be plans in place as it's a nice thing to do and there is a lot to cover that may require concerted efforts by the whole team.
It would be nice if I could learn them and maybe contribute to the task.
For now, I am thinking maybe I can start working on most of the documentations, comments, and even tests that have the terminology but wouldn't affect the code that is run in production.
Updated by xtkoba (Tee KOBAYASHI) over 3 years ago
[redacted due to inappropriate expression]
Updated by matz (Yukihiro Matsumoto) over 3 years ago
As basic principles:
- I think
master
without correspondingslave
is still OK (e.g.master
branch in git). - compatibility is more important than political correctness, so we are not going to change any API, for example,
Socket::IFF_SLAVE
. - when we might add replacements for
slave
, they should follow standard/convention of the platform (Linux/Unix does not provide replacement forIFF_SLAVE
yet) - we are not going to modify the past history, so that
ChangeLog
and past documents should be kept as they are.
Following those principles, we can only change some variable names in ext/pty
code & docuement at most.
Matz.
Updated by zzak (zzak _) over 3 years ago
I would defer to @hsbt (Hiroshi SHIBATA) on how difficult it would be to change the default branch in git. I'm happy to review and merge any patches that offer alternative (either code using alias for backwards compatibility) or documentation.
Updated by sawa (Tsuyoshi Sawada) over 3 years ago
zzak (Zachary Scott) wrote in #note-3:
I would defer to @hsbt (Hiroshi SHIBATA) on how difficult it would be to change the default branch in git.
Do you mean replacing "master"? Although I agree with avoiding the word "slave", I agree with Matz, and I do not see any point in deprecating the word master. Whereas the word master implies master-slave relation only in the context of slavery, the word slave means nothing else (in present English). They are different. The word master is used in wide context, such as the boss in an employment relation. And once you start claiming against the use of the word "master", what are you going to do with "master's degree", "Master Card", "masterpiece", etc.?
Updated by zzak (zzak _) over 3 years ago
For me, having different branch names is just a quality of life improvement. Every project at my company has switched to "main", and many OSS projects I hack on have as well. Having to remember which one uses "main" and which one uses "master" is annoying and I constantly have to double check when I am push/pull'ing. It would be nice if Ruby switched for me to avoid this issue, but I reckon that is not so easy task.
Updated by duerst (Martin Dürst) over 3 years ago
- Related to Misc #15843: Make "trunk" a symbolic-ref of "master" on git.ruby-lang.org added
Updated by duerst (Martin Dürst) over 3 years ago
zzak (Zachary Scott) wrote in #note-5:
For me, having different branch names is just a quality of life improvement. Every project at my company has switched to "main", and many OSS projects I hack on have as well. Having to remember which one uses "main" and which one uses "master" is annoying and I constantly have to double check when I am push/pull'ing. It would be nice if Ruby switched for me to avoid this issue, but I reckon that is not so easy task.
Just for reference, we have switched from trunk to master before (see #15843), so we have some experience with how to do this.
Updated by Skade (Florian Gilcher) over 3 years ago
For reference, the Rust project decided to switch to main
because it is the tools default and running on defaults has value.
Still, it's doing so on a relaxed timeline: https://internals.rust-lang.org/t/changing-the-default-branch-from-master-to-main/14520/6
The main
problem here is making sure that tooling that encodes master
as a name (instead of rev-parsing HEAD and checking it out) may break. This may include build pipelines of users out there building and integrating software. As @duerst (Martin Dürst) lines out, this has already been done by adding a symbolic-ref.
We did not find rehashing discussions useful, considering that upstream git has had that discussion and opted for a new default.
Updated by hsbt (Hiroshi SHIBATA) over 3 years ago
- Status changed from Open to Closed
We should only update the documentation and code on etc/pty
. I totally agreed the Matz's opinion.