You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yunikorn.apache.org by Wilfred Spiegelenburg <wi...@apache.org> on 2023/01/27 00:25:45 UTC

[DISCUSS] Inclusive language: change git default branch name

The naming of our default branch master, while very common, can be seen as
offensive.
I would like to propose that after the release of YuniKorn 1.2 we rename
our default branch from master to "trunk". There are other options like:
"main" or "development".

We cannot execute the rename ourselves and need the help of the Apache
Infra team. After this change we will need to update github workflows,
documentation and some of the tools we use.

After the renaming, all local clones will need to be updated to point to
the trunk. The process of how to do that is well documented [1] but it does
require action from everyone.

two things that we need to confirm:
* the timing first action after the release of YuniKorn 1.2
* the name of the new default branch to become "trunk"

Wilfred

[1]
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch#updating-a-local-clone-after-a-branch-name-changes

Re: [DISCUSS] Inclusive language: change git default branch name

Posted by Weiwei Yang <ww...@apache.org>.
Let's decide this with Apache way and vote to a consensus.
I am -1 on this. If this is an effortless change, I will be +0, but this
needs a ton of effort. Also lots of implications we couldn't even realize
today.  I don't think we need to debate if the "master" word is offensive
or not, this is something really personal, and I respect different
opinions. But as an OSS community, we focus on building good sustainable
software, it is not necessarily (or best not to) to do changes like this.
That's my opinion.

Weiwei

On Fri, Jan 27, 2023 at 8:59 AM Craig Condit <cc...@apache.org> wrote:

> This will probably be an unpopular opinion, but I’m -1 on this. I agree
> with being inclusive where it makes sense, however this whole “master vs.
> main” controversy is rooted in an idea that is ill-informed, ill-conceived,
> and provides no technical benefit. I’ll make my case as follows:
>
> 1. Ill-informed
>   - Myth: “master” as used in Git is reflective of slavery
>   - Fact: Words mean drastically different things in different contexts.
> The word “master” has 26 distinct definitions (
> https://www.dictionary.com/browse/master), only 1 of which has any
> connection with slavery. The most appropriate definition of “master” as
> used within Git would probably be 23: “Computers. An original data file or
> disk from which duplicates may be made.” This definition also follows from
> the previous one as used in audio recording. 22b: "an audio disk or tape
> from which duplicates may be made”.
>   - Conclusion: The desire to eradicate “master” from technology is rooted
> in a false premise that it has connections with slavery. Clearly, **when
> used in context** it does not. If we believe there is merit in removing
> "master” from git, should we also remove “master’s degrees”, honorary
> titles (Master Smith), ship captains (Master Mariner), recording masters,
> photographic masters, descriptions of the highly skilled: “chess master”,
> “grandmaster”, “schoolmaster”? Where does it stop?
>
> 2. Ill-Conceived
>   - Myth: Changing the branch name is free (or low cost)
>   - Fact: A change like this is anything but free. Having gone through
> this several times in the past, I can confidently say we will be dealing
> with the technical fallout of this for months if not longer. Every
> reference to the code, both publicly and privately, has to be updated. This
> includes not only working copies, but CI/CD pipelines, including for any
> user or company that maintains their own. There’s a “flag day” where
> everything prior is now irrevocably divorced from what comes after. Since
> we have multiple repositories, there’s now inter-repository work as well.
>   - Conclusion: This change would create a tremendous amount of technical
> debt.
>
> Racism, slavery, and exploitation are real issues that have been plaguing
> humanity since there have been multiple different people around. They won’t
> be solved by excising words from our vocabulary (especially those with
> legitimate technical definitions) and only serve to let people give
> themselves a pat on the back.  Want to make a real difference? Donate time
> or resources to one of many organizations working to end things like human
> trafficking. That will provide far more benefit than any mass rename of
> code.
>
> To those who may be tempted to find the use of the word “master” as used
> in Git offensive: I would encourage you to educate yourself about the
> nuance of language and recognize that the offense is in how people treat
> each other, and not in what words are deemed today as “ok” and tomorrow as
> “off-limits”.
>
>
> Craig
>
>
> > On Jan 26, 2023, at 6:25 PM, Wilfred Spiegelenburg <wi...@apache.org>
> wrote:
> >
> > The naming of our default branch master, while very common, can be seen
> as
> > offensive.
> > I would like to propose that after the release of YuniKorn 1.2 we rename
> > our default branch from master to "trunk". There are other options like:
> > "main" or "development".
> >
> > We cannot execute the rename ourselves and need the help of the Apache
> > Infra team. After this change we will need to update github workflows,
> > documentation and some of the tools we use.
> >
> > After the renaming, all local clones will need to be updated to point to
> > the trunk. The process of how to do that is well documented [1] but it
> does
> > require action from everyone.
> >
> > two things that we need to confirm:
> > * the timing first action after the release of YuniKorn 1.2
> > * the name of the new default branch to become "trunk"
> >
> > Wilfred
> >
> > [1]
> >
> https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch#updating-a-local-clone-after-a-branch-name-changes
>
>

Re: [DISCUSS] Inclusive language: change git default branch name

Posted by Craig Condit <cc...@apache.org>.
This will probably be an unpopular opinion, but I’m -1 on this. I agree with being inclusive where it makes sense, however this whole “master vs. main” controversy is rooted in an idea that is ill-informed, ill-conceived, and provides no technical benefit. I’ll make my case as follows:

1. Ill-informed
  - Myth: “master” as used in Git is reflective of slavery
  - Fact: Words mean drastically different things in different contexts. The word “master” has 26 distinct definitions (https://www.dictionary.com/browse/master), only 1 of which has any connection with slavery. The most appropriate definition of “master” as used within Git would probably be 23: “Computers. An original data file or disk from which duplicates may be made.” This definition also follows from the previous one as used in audio recording. 22b: "an audio disk or tape from which duplicates may be made”.
  - Conclusion: The desire to eradicate “master” from technology is rooted in a false premise that it has connections with slavery. Clearly, **when used in context** it does not. If we believe there is merit in removing "master” from git, should we also remove “master’s degrees”, honorary titles (Master Smith), ship captains (Master Mariner), recording masters, photographic masters, descriptions of the highly skilled: “chess master”, “grandmaster”, “schoolmaster”? Where does it stop?

2. Ill-Conceived
  - Myth: Changing the branch name is free (or low cost)
  - Fact: A change like this is anything but free. Having gone through this several times in the past, I can confidently say we will be dealing with the technical fallout of this for months if not longer. Every reference to the code, both publicly and privately, has to be updated. This includes not only working copies, but CI/CD pipelines, including for any user or company that maintains their own. There’s a “flag day” where everything prior is now irrevocably divorced from what comes after. Since we have multiple repositories, there’s now inter-repository work as well.
  - Conclusion: This change would create a tremendous amount of technical debt.

Racism, slavery, and exploitation are real issues that have been plaguing humanity since there have been multiple different people around. They won’t be solved by excising words from our vocabulary (especially those with legitimate technical definitions) and only serve to let people give themselves a pat on the back.  Want to make a real difference? Donate time or resources to one of many organizations working to end things like human trafficking. That will provide far more benefit than any mass rename of code.

To those who may be tempted to find the use of the word “master” as used in Git offensive: I would encourage you to educate yourself about the nuance of language and recognize that the offense is in how people treat each other, and not in what words are deemed today as “ok” and tomorrow as “off-limits”.


Craig


> On Jan 26, 2023, at 6:25 PM, Wilfred Spiegelenburg <wi...@apache.org> wrote:
> 
> The naming of our default branch master, while very common, can be seen as
> offensive.
> I would like to propose that after the release of YuniKorn 1.2 we rename
> our default branch from master to "trunk". There are other options like:
> "main" or "development".
> 
> We cannot execute the rename ourselves and need the help of the Apache
> Infra team. After this change we will need to update github workflows,
> documentation and some of the tools we use.
> 
> After the renaming, all local clones will need to be updated to point to
> the trunk. The process of how to do that is well documented [1] but it does
> require action from everyone.
> 
> two things that we need to confirm:
> * the timing first action after the release of YuniKorn 1.2
> * the name of the new default branch to become "trunk"
> 
> Wilfred
> 
> [1]
> https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch#updating-a-local-clone-after-a-branch-name-changes