[llvm-dev] Inclusive language in LLVM: can we rename `master` branch?

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Sat Jun 20 18:00:13 PDT 2020


Hi All,

I am perfectly aware that `master` has other significations than the
> master/slave meaning, and I personally never made this association in the
> past. However I'm also able to recognize that I'm privileged here, and that
> not everyone is in the same position.


No objection to renaming the branch. I definitely like the idea of staying
consistent with whatever github is doing.

But on process for this kind of thing: Has anyone actually complained about
the name of the master branch? I can see a strong motivation for removing
master/slave terminology from projects, but the name "master" for the
primary branch of a project almost certainly comes from this sense of the
word [1]:

"13. The original of a document or of a recording.
e.g. The band couldn't find the master, so they re-recorded their tracks."

If the bar for removal / renaming is "Use of X is offensive", or "Use of X
is clearly impacting contributors or potential contributors" then I'm all
for it. If the bar is "Nobody has actually complained, but X could be
mistaken for something offensive" that seems like a low bar.

-- Lang.

[1] https://en.wiktionary.org/wiki/master#English

On Sat, Jun 20, 2020 at 4:03 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Sat, Jun 20, 2020 at 3:31 PM James Courtier-Dutton <
> james.dutton at gmail.com> wrote:
>
>> Hi,
>>
>> I am more confused than anything else.
>> There are whole areas of data design and management called "Master
>> Data Management".
>> In financial statements there is the expression "In the black" meaning
>> a good positive figure in the balance sheet,
>
>
> I'm glad to hear that there are positive uses of the word "black"!
>
>
>
>> and "in the red" and a
>> bad negative figure.
>> So, for the confused people like me, I would prefer someone to come up
>> with a list of words (and in what context) that are offensive, and
>> then we can easily avoid them in future.
>
>
> It is hard to have an exhaustive list, but I'm sure we can come up with a
> list of resources to link to from our docs (coding standards for example),
> I pointed to IETF doc
> <https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1> in
> the original post, Google also has a doc on Writing inclusive
> documentation
> <https://developers.google.com/style/inclusive-documentation>,
>
>
>
>> I am sure, like me, that none
>> of us wish or have ever wished to use offensive words.
>> I get the feeling that people are having to guess at the moment, Is
>> "xyz" offensive?
>>
>
> I am fairly confident that "xyz" is OK :)
>
> Best,
>
> --
> Mehdi
>
>
>
>>
>> Kind Regards
>>
>> James
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, 19 Jun 2020 at 10:49, Mehdi AMINI via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > Hi,
>> >
>> > When we moved to GitHub a few months ago, we used without more
>> consideration the "master" convention to name our development branch. On
>> SVN it used to be just "trunk".
>> > This naming is unfortunate as it can hurt some contributors, and there
>> is really no technical advantage that I know of to favor this convention
>> over another.
>> >
>> > I am perfectly aware that `master` has other significations than the
>> master/slave meaning, and I personally never made this association in the
>> past. However I'm also able to recognize that I'm privileged here, and that
>> not everyone is in the same position.
>> >
>> > As we intend to be an inclusive community, I propose that we change the
>> name of our development branch and that we adopt instead a more neutral
>> terminology for the LLVM monorepo. Possible names are "dev", "trunk",
>> "main", "default", ...
>> >
>> > We need to plan a transition as all the bots will need to be updated to
>> track this new branch instead, but these are minor technical details,
>> nothing compared to the SVN->Git migration we went through.
>> >
>> > Since I'm on this topic, we should also likely look into the pervasive
>> use of whitelist/blacklist in the project.
>> >
>> > Thoughts?
>> >
>> > --
>> > Mehdi
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200620/ad9ba569/attachment-0001.html>


More information about the llvm-dev mailing list