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

[Eric Christopher via llvm-dev]

On Fri, Jun 19, 2020 at 1:15 PM Eric Christopher <echristo at gmail.com> wrote:

>
>
> On Fri, Jun 19, 2020 at 1:09 PM Fangrui Song via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> On 2020-06-19, Justin Hibbits via llvm-dev wrote:
>> >On Fri, 19 Jun 2020 17:38:02 +0100
>> >Renato Golin <rengolin at gmail.com> wrote:
>> >
>> >> On Fri, 19 Jun 2020 at 16:43, Robinson, Paul via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >> > If anyone's keeping track of the voting:
>> >> > +1 for "dev" (contrasts with "release")
>> >> > +1 for "trunk" (historical and consistent with the branch metaphor)
>> >> > -1 for "main"
>> >>
>> >> Hey! At least one +1 for "main" from me!
>> >>
>> >> Also, on -1 for "trunk" from Arm.
>> >>
>> >> I may have missed some, too.
>> >>
>> >> I agree with Chris we should wait for Github, mostly because that
>> >> would be looking over a much wider scope and will be choosing
>> >> something that more people are happy with.
>> >>
>> >> Moreover, more people will use the Github name as their main branch
>> >> and will be "surprised" why ours is different and we'll have to
>> >> explain.
>> >>
>> >> Least surprise principle is always good.
>> >
>> >This is a reason I can support... least surprise, consistent with other
>> >projects on the platform.  However I may disagree with the reasoning
>> >behind GitHub's changing (which reeks of arrogance on their part),
>> >maintaining consistency of this project for users of other projects on
>> >the platform is respectable and acceptable.
>> >
>> >- Justin
>>
>> I agree that we should just wait for Github.
>>
>> * Paul Robinson
>> >> On Fri, 19 Jun 2020 14:46:19 +0000
>> >> "Keane, Erich via llvm-dev" <llvm-dev at lists.llvm.org> wrote:
>> >>
>> >> > If the name of our branch causes anxiety/difficulty for a significant
>> >> > portion of our population, it is literally the least we can do to
>> >> > choose a word that better respects the last few centuries of world
>> >> > history.
>> >>
>> >> Honestly, if the name of a branch causes anxiety/difficulty, that's an
>> >> issue on that population.
>> >
>> >Much as I hate to use this sort of language, that statement appears to
>> >be blaming the victim for not getting over it and progressing to a
>> >connotation-free reading of language.  But language is never free of
>> >connotations, even if you and I don't see those connotations.
>> >
>> >I'm not seeing the change as a huge inconvenience, and this argument is
>> >not much different than the head-butting over camelCase vs CamelCase.
>> >Some people care deeply, others see little value in the change so why
>> >bother; IMO it makes the people who care deeply happier, and it doesn't
>> >particularly interfere with my work or cost me more than a bit of one
>> >time adaptation.  Thus overall it is a plus for the community.
>> >
>> >If anyone's keeping track of the voting:
>> >+1 for "dev" (contrasts with "release")
>> >+1 for "trunk" (historical and consistent with the branch metaphor)
>> >-1 for "main"
>> >--paulr
>>
>> +1 for dev
>> +1 for trunk
>>
>>
>>
>> The majority of people replying here seem to in favor of migrating off
>> from 'master'. I still wanted to share the origin of 'master copy' and an
>> opinion from the other side
>>
>> http://antirez.com/news/122
>
>
> I disagree with any attempt to "both sides" this issue. There's no reason
> to have done this.
>
>
To elaborate a bit: we should change the wording because it has been shown
to be more inclusive and does actually matter. To the rest of the
suggestions in the article: we should do those too. There's no reason to
put out a dichotomy here.

-eric


> -eric
>
>
>>
>> _______________________________________________
>> 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/20200619/842a7fd7/attachment.html>