Project

General

Profile

Actions

Misc #17828

closed

Deprecate use of master and slave

Added by yyoshida.at.work@gmail.com (Yasuhiro Yoshida) 3 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
[ruby-core:103593]

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.


Related issues

Related to Ruby master - Misc #15843: Make "trunk" a symbolic-ref of "master" on git.ruby-lang.orgClosedk0kubun (Takashi Kokubun)Actions

Updated by xtkoba (Tee KOBAYASHI) 3 months ago

[redacted due to inappropriate expression]

Updated by matz (Yukihiro Matsumoto) 3 months ago

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.

Updated by zzak (Zachary Scott) 3 months 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) 3 months 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 (Zachary Scott) 3 months 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.

Actions #6

Updated by duerst (Martin Dürst) 3 months ago

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

Updated by duerst (Martin Dürst) 3 months 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) 3 months 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) 3 months 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.

Actions

Also available in: Atom PDF