Misc #17828: Deprecate use of master and slave

• Status: Closed
• Assignee: -

[[e-mail] (Yasuhiro Yoshida)]

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.

[xtkoba (Tee KOBAYASHI)]

[redacted due to inappropriate expression]

[matz (Yukihiro Matsumoto)]

As basic principles:

• I think master without corresponding slave 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 for IFF_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.

[zzak (zzak _)]

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.

[sawa (Tsuyoshi Sawada)]

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.?

[zzak (zzak _)]

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.

[duerst (Martin Dürst)]

• Related to Misc #15843: Make "trunk" a symbolic-ref of "master" on git.ruby-lang.org added

[duerst (Martin Dürst)]

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.

[Skade (Florian Gilcher)]

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.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Closed

We should only update the documentation and code on etc/pty. I totally agreed the Matz's opinion.