Rename "master" branch to "main"?

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
Community,

As we approach the release boundary for 2.32 we come to a natural point
where we can rename our development and release branch.

Red Hat CTO Chris Wright wrote about this recently:
https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language

LWN also wrote about this recently in "Loaded terms in free software":
https://lwn.net/Articles/823224/

Github is committed to changing the default development branch to "main":
https://twitter.com/natfriedman/status/1271253144442253312

There are open requests for Gitlab to adopt "main" as the default branch name:
https://gitlab.com/gitlab-org/gitlab/-/issues/220906
https://gitlab.com/gitlab-org/gitlab/-/issues/222204

My proposal would be to rename the development and current release branch:

* master -> main

* release/2.32/master -> release/2.32/main

This proposal is only about the development branch and upcoming release
branch. Please start a new thread to discuss the historical branch names
or other relevant issues.

My concern is that git, as a project, has not yet changed their default,
and it would be beneficial to match their default name. I am OK with
waiting for the git project to make a choice before changing our branch
name to match.

Comments?

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Paul Eggert
On 6/30/20 11:10 AM, Carlos O'Donell via Libc-alpha wrote:
> My concern is that git, as a project, has not yet changed their default,
> and it would be beneficial to match their default name. I am OK with
> waiting for the git project to make a choice before changing our branch
> name to match.
>
> Comments?

My preference is to not wait. Waiting won't help solve compatibility issues
(e.g., mismatch between our default's and Git's), as they'll need to be solved
anyway.
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
* Carlos O'Donell via Libc-alpha:

> My concern is that git, as a project, has not yet changed their default,

I don't think this matters because the default branch during clone is
set by the server.  The default branch set by “git init” does not really
matter to glibc development.

Thanks,
Florian

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
On 6/30/20 2:59 PM, Florian Weimer wrote:
> * Carlos O'Donell via Libc-alpha:
>
>> My concern is that git, as a project, has not yet changed their default,
>
> I don't think this matters because the default branch during clone is
> set by the server.  The default branch set by “git init” does not really
> matter to glibc development.

It matters only in the sense that developers will become comfortable
with making new repositories, and the default branch in those new
repositories will be something, and that will become the new normal
for developers.

For example if we switched to "main" and the rest of the developer
community switches to "trunk" then we have to explain that our "main"
is the equivalent of the default "trunk" created by git init when
you start a project.

I have no objection over using "main" today, just a concern to stay
aligned with the default development branch name used by git init.

Does that clarify my position?

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Paul Eggert
On 6/30/20 2:35 PM, Paul Eggert wrote:

> On 6/30/20 11:10 AM, Carlos O'Donell via Libc-alpha wrote:
>> My concern is that git, as a project, has not yet changed their default,
>> and it would be beneficial to match their default name. I am OK with
>> waiting for the git project to make a choice before changing our branch
>> name to match.
>>
>> Comments?
>
> My preference is to not wait. Waiting won't help solve compatibility issues
> (e.g., mismatch between our default's and Git's), as they'll need to be solved
> anyway.

Just to be clear, which of the two options are you advocating:

(a) Rename "master" immediately to "main"

or

(b) When "master" is frozen for the 2.32 release we rename
    to "main" along with creating "release/2.32/main" and
    publish the new branch names to be used by developers
    when development reopens.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Paul Eggert
On 6/30/20 1:16 PM, Carlos O'Donell wrote:

> Just to be clear, which of the two options are you advocating:
>
> (a) Rename "master" immediately to "main"
>
> or
>
> (b) When "master" is frozen for the 2.32 release we rename
>     to "main" along with creating "release/2.32/main" and
>     publish the new branch names to be used by developers
>     when development reopens.

Either's fine with me. I just don't want to wait until the default name is
changed in Git (or in Savannah or GitHub or whatever).

That is, we should change the name at a time that's good for glibc, and not
worry too much about when other projects change. No matter when we change we'll
have to deal with developers running with older or newer versions of Git (or
whatever) and so we'll need to deal with mismatches between the glibc branch
name and the Git default (or whatever).
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Joseph Myers
In reply to this post by Sourceware - libc-alpha mailing list
On Tue, 30 Jun 2020, Carlos O'Donell via Libc-alpha wrote:

> My proposal would be to rename the development and current release branch:
>
> * master -> main
>
> * release/2.32/master -> release/2.32/main

Have you reviewed the git hooks and hook configuration to identify
anything that special-cases master or branch names involving "master"?  
For example, configuration of which branches do or do not allow
non-fast-forward pushes / merge commits / ...?

Do you have all the wiki updates that would be required prepared?  In
particular, detailed instructions for updating existing clones that have
branches tracking master?

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
On 6/30/20 5:24 PM, Joseph Myers wrote:

> On Tue, 30 Jun 2020, Carlos O'Donell via Libc-alpha wrote:
>
>> My proposal would be to rename the development and current release branch:
>>
>> * master -> main
>>
>> * release/2.32/master -> release/2.32/main
>
> Have you reviewed the git hooks and hook configuration to identify
> anything that special-cases master or branch names involving "master"?  
> For example, configuration of which branches do or do not allow
> non-fast-forward pushes / merge commits / ...?

I have access to and can review all of that code. Florian and I set it all
up on sourceware.

I see only 1 reference in the hooks to "master" and it's for computing a
short name for email subjects that eschews the branch name (updates/branches/update.py).

The rest is driven entirely by direct references to what is being committed.

We will have to update the configuration of the hooks once the branch is
renamed.
 
> Do you have all the wiki updates that would be required prepared?  In
> particular, detailed instructions for updating existing clones that have
> branches tracking master?
 
No, we would need to update GlibcGit with new information.

Also providing instructions to update existing clones would be needed and
we need to work that out, but since many people are working this out it
should be a straight forward process.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Joseph Myers
On Tue, 30 Jun 2020, Carlos O'Donell via Libc-alpha wrote:

> I see only 1 reference in the hooks to "master" and it's for computing a
> short name for email subjects that eschews the branch name
> (updates/branches/update.py).

That hardcoding is still present in the latest version of the hooks so
that should be reported as an issue at
https://github.com/AdaCore/git-hooks/issues (I think it's reasonably
different from my existing https://github.com/AdaCore/git-hooks/issues/8 
for customization of commit messages and hooks - a better upstream default
would probably be for the hooks to determine automatically what the
default branch for new clones is, and treat that branch specially, rather
than needing a separate hooks configuration option to identify that
branch).  Note that glibc uses a symlink to a shared installation of the
hooks used by other sourceware projects (but not by GCC which has its own
copy with further local changes).

In hooks-bin, email-to-bugzilla-filtered checks for master (and for
release branches) to determine whether to report a commit to Bugzilla.  
Likewise post-receive for irker (although that seems to have been broken
for some time anyway, I think because of freenode configuration changes).  
So the above reference is not the only one.

refs/meta/config:project.config has

        allow-non-fast-forward = (?!master|release.*)

so that would also need updating.

I don't know if there might be other places.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
"Carlos O'Donell via Libc-alpha" <[hidden email]> writes:
> My proposal would be to rename the development and current release branch:
>
> * master -> main
>
> * release/2.32/master -> release/2.32/main

I will pose the unpopular opinion that the cost of this change[1] is
higher than the value of the change.  The word "master" has many
meanings, and even in this case the context (and thus meaning) has
changed over time.  Since we use "master" in the adjective case (master
branch), and don't use the word "slave" anywhere (we use
master/release), IMHO this is a case where we've gone too far down the
slippery slope and are making a change for the sake of looking good and
not for the sake of actually improving anything.  Our efforts to
*actually* be inclusive have been far more useful and meaningful than
any efforts to just *appear* inclusive, and we should continue to apply
our efforts in that manner, such as responding more timely to new people
on the mailing list and IRC, or reviewing patches.

If we want to rename the master branch to a more meaningful name, there
are far more meaningful choices than "main".  "Trunk" goes with the
"branch" metaphor.  How about "development"?  We have an opportunity to
pick something precise and obvious, let's not waste it by blindly
following others.

[1] scripts, docs, training, everyone's existing git repos, confusion, etc

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Andreas Schwab-2
On Jun 30 2020, DJ Delorie via Libc-alpha wrote:

> I will pose the unpopular opinion that the cost of this change[1] is
> higher than the value of the change.

I agree.  There are also numerous other branches using that name.

> If we want to rename the master branch to a more meaningful name, there
> are far more meaningful choices than "main".  "Trunk" goes with the
> "branch" metaphor.  How about "development"?

Since we use master for both development and release branches, neither
trunk nor development really fit here.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
* Carlos O'Donell:

> For example if we switched to "main" and the rest of the developer
> community switches to "trunk" then we have to explain that our "main"
> is the equivalent of the default "trunk" created by git init when
> you start a project.
>
> I have no objection over using "main" today, just a concern to stay
> aligned with the default development branch name used by git init.
>
> Does that clarify my position?

Yes, it does.  I think it's unlikely that git chooses something that is
not the Github default.  Skimming the git list, I think people are
leaning towards “main” *if* they want to make a change at all.

Thanks,
Florian

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list


On 30/06/2020 19:59, DJ Delorie via Libc-alpha wrote:

> "Carlos O'Donell via Libc-alpha" <[hidden email]> writes:
>> My proposal would be to rename the development and current release branch:
>>
>> * master -> main
>>
>> * release/2.32/master -> release/2.32/main
>
> I will pose the unpopular opinion that the cost of this change[1] is
> higher than the value of the change.  The word "master" has many
> meanings, and even in this case the context (and thus meaning) has
> changed over time.  

I tend to agree with you and this 'master' meaning is even more nebulous
in other languages context (on portuguese, for instance, its direct
translation is 'mestre' which is does not have the same historical baggage
as in english, the derogatory meaning is more associated with 'senhor'
which directly translate to 'mister' or 'lord').

Since we use "master" in the adjective case (master
> branch), and don't use the word "slave" anywhere (we use
> master/release), IMHO this is a case where we've gone too far down the
> slippery slope and are making a change for the sake of looking good and
> not for the sake of actually improving anything.  Our efforts to
> *actually* be inclusive have been far more useful and meaningful than
> any efforts to just *appear* inclusive, and we should continue to apply
> our efforts in that manner, such as responding more timely to new people
> on the mailing list and IRC, or reviewing patches.

Totally agree, the pragmatic gain with this chance does not address or
improve any of the points you noted. A program of active mentoring, for
instance, would be way more effective (just to give an example).

>
> If we want to rename the master branch to a more meaningful name, there
> are far more meaningful choices than "main".  "Trunk" goes with the
> "branch" metaphor.  How about "development"?  We have an opportunity to
> pick something precise and obvious, let's not waste it by blindly
> following others.

I am still doubtful if we should really change the branch name.

>
> [1] scripts, docs, training, everyone's existing git repos, confusion, etc
>
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
On 7/1/20 8:29 AM, Adhemerval Zanella via Libc-alpha wrote:

> On 30/06/2020 19:59, DJ Delorie via Libc-alpha wrote:
>> "Carlos O'Donell via Libc-alpha" <[hidden email]> writes:
>>> My proposal would be to rename the development and current release branch:
>>>
>>> * master -> main
>>>
>>> * release/2.32/master -> release/2.32/main
>>
>> I will pose the unpopular opinion that the cost of this change[1] is
>> higher than the value of the change.  The word "master" has many
>> meanings, and even in this case the context (and thus meaning) has
>> changed over time.  
>
> I tend to agree with you and this 'master' meaning is even more nebulous
> in other languages context (on portuguese, for instance, its direct
> translation is 'mestre' which is does not have the same historical baggage
> as in english, the derogatory meaning is more associated with 'senhor'
> which directly translate to 'mister' or 'lord').

In the context of git, the term "master" was taken from bitkeeper, and
there it used as a master/slave context for repositories. The irony is that
git is a dvcs, there is no "master" repository in the context of the design
of the framework.

> Since we use "master" in the adjective case (master
>> branch), and don't use the word "slave" anywhere (we use
>> master/release), IMHO this is a case where we've gone too far down the
>> slippery slope and are making a change for the sake of looking good and
>> not for the sake of actually improving anything.  Our efforts to
>> *actually* be inclusive have been far more useful and meaningful than
>> any efforts to just *appear* inclusive, and we should continue to apply
>> our efforts in that manner, such as responding more timely to new people
>> on the mailing list and IRC, or reviewing patches.
>
> Totally agree, the pragmatic gain with this chance does not address or
> improve any of the points you noted. A program of active mentoring, for
> instance, would be way more effective (just to give an example).
 
We should do *both*!

I have a mentoring program that I'm running within Red Hat to train an
additional person in glibc development, and I think it's going well.

If the internal mentoring goes well I will extend it to external mentoring
in 2021 for new developers on an annual basis.

>> If we want to rename the master branch to a more meaningful name, there
>> are far more meaningful choices than "main".  "Trunk" goes with the
>> "branch" metaphor.  How about "development"?  We have an opportunity to
>> pick something precise and obvious, let's not waste it by blindly
>> following others.
>
> I am still doubtful if we should really change the branch name.

The branch renaming is a non-recurring engineering cost for us to
transition. It has no ongoing cost, unlike a mentoring program, which has
a sustained cost forever. Thus the cost of the rename is minor compared
to the cost of the mentoring project.

We have at least two instances of identified problematic language in the
source repository. At the end of the day, for me, it's just a search and
replace away from being fixed. I don't care what we call it. I do care
that a group of people have asked us to change it.

I'm not in a position to judge anyone's feelings, but I am in a position
to act and make others feel more included with a change in branch name.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list


On 01/07/2020 09:49, Carlos O'Donell wrote:

> On 7/1/20 8:29 AM, Adhemerval Zanella via Libc-alpha wrote:
>> On 30/06/2020 19:59, DJ Delorie via Libc-alpha wrote:
>>> "Carlos O'Donell via Libc-alpha" <[hidden email]> writes:
>>>> My proposal would be to rename the development and current release branch:
>>>>
>>>> * master -> main
>>>>
>>>> * release/2.32/master -> release/2.32/main
>>>
>>> I will pose the unpopular opinion that the cost of this change[1] is
>>> higher than the value of the change.  The word "master" has many
>>> meanings, and even in this case the context (and thus meaning) has
>>> changed over time.  
>>
>> I tend to agree with you and this 'master' meaning is even more nebulous
>> in other languages context (on portuguese, for instance, its direct
>> translation is 'mestre' which is does not have the same historical baggage
>> as in english, the derogatory meaning is more associated with 'senhor'
>> which directly translate to 'mister' or 'lord').
>
> In the context of git, the term "master" was taken from bitkeeper, and
> there it used as a master/slave context for repositories. The irony is that
> git is a dvcs, there is no "master" repository in the context of the design
> of the framework.

And this is example of connotation lost in history, the 'master' here has
even less connection of its original meaning.

>
>> Since we use "master" in the adjective case (master
>>> branch), and don't use the word "slave" anywhere (we use
>>> master/release), IMHO this is a case where we've gone too far down the
>>> slippery slope and are making a change for the sake of looking good and
>>> not for the sake of actually improving anything.  Our efforts to
>>> *actually* be inclusive have been far more useful and meaningful than
>>> any efforts to just *appear* inclusive, and we should continue to apply
>>> our efforts in that manner, such as responding more timely to new people
>>> on the mailing list and IRC, or reviewing patches.
>>
>> Totally agree, the pragmatic gain with this chance does not address or
>> improve any of the points you noted. A program of active mentoring, for
>> instance, would be way more effective (just to give an example).
>  
> We should do *both*!
>
> I have a mentoring program that I'm running within Red Hat to train an
> additional person in glibc development, and I think it's going well.
>
> If the internal mentoring goes well I will extend it to external mentoring
> in 2021 for new developers on an annual basis.

This is a excellent initiative and I glad to help if possible. But I still
doubtful that playing with technological terms still yield any pragmatic
change here.

>
>>> If we want to rename the master branch to a more meaningful name, there
>>> are far more meaningful choices than "main".  "Trunk" goes with the
>>> "branch" metaphor.  How about "development"?  We have an opportunity to
>>> pick something precise and obvious, let's not waste it by blindly
>>> following others.
>>
>> I am still doubtful if we should really change the branch name.
>
> The branch renaming is a non-recurring engineering cost for us to
> transition. It has no ongoing cost, unlike a mentoring program, which has
> a sustained cost forever. Thus the cost of the rename is minor compared
> to the cost of the mentoring project.
>
> We have at least two instances of identified problematic language in the
> source repository. At the end of the day, for me, it's just a search and
> replace away from being fixed. I don't care what we call it. I do care
> that a group of people have asked us to change it.
>
> I'm not in a position to judge anyone's feelings, but I am in a position
> to act and make others feel more included with a change in branch name.
>

I agree this is minor issue and might just be an just an annoyance for
some users (that might need to adapt some tools or scripts). And I don't
want to delve into in the personal reasons someone asked for this change
(it is a can of worm that can derail this discussion).

My point is just that although this change has zero cost pragmatically it
will most likely has zero outcome. In fact in with current turbulent
ideological clash worldwide I see this kind of change as more alienating
than beneficial.
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Andreas Schwab-2
On 7/1/20 3:17 AM, Andreas Schwab wrote:
> There are also numerous other branches using that name.

Just to be clear I am not proposing a rewriting of any git history
or changing any existing branches, only the names of new branches
going forward along with the development branch. Hopefully my
initial email was clear on that topic.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
On 6/30/20 6:59 PM, DJ Delorie wrote:
> "Carlos O'Donell via Libc-alpha" <[hidden email]> writes:
>> My proposal would be to rename the development and current release branch:
>>
>> * master -> main
>>
>> * release/2.32/master -> release/2.32/main
>
> I will pose the unpopular opinion that the cost of this change[1] is
> higher than the value of the change.

A group of people have identified problematic language.

Without judgement, consider their request, and accept that what
they tell you is their truth, that the language *is* problematic
to them and that you have the capability to make a change and
be more inclusive to this group.

Changing the branches is easy. Yes it has costs, but those costs
are limited in scope.

Problematic language will *never end* and it will always be our
responsibility to listen to people who are impacted by such
language and then decide if we act or not.

We as a community choose how we act.

I would not go forward with any change that lacks consensus.

I accept that some people will have objections.

Some developers have applied their own metrics and evaluated the
value to be below the threshold for action. My opinion is that such
evaluations are far more complex to make than people would like to
admit, and that such valuations are not required to decide on an
action.

The choice is one of either supporting the inclusion of the group
claiming the language to be problematic or choosing not to be
inclusive of that group and their request.

I find the strongest argument for inaction is made by Adhemerval [1].
That the current optics of this change can draw negative toxic
attention to the project and cause problems for existing developers
who do not deserve such toxicity. My only response to this is that
as a Steward I would not stand for any such toxicity on this list
or in the community and would immediately and decisively act to
remove it. Having said that, there are a lot of digital places I
have no influence or control over.

Feel free to judge me on my past inaction, particularly with
regards to the abort cartouche changes; with my only defense
being that we did act in the end. I do not plan to repeat the same
mistakes.

The name of the branch doesn't matter to me, but it matters to
someone else, and that's what matters. I am willing to exert
effort to change this, just like I'm willing to exert effort
to mentor new people [2].

--
Cheers,
Carlos.

[1] https://sourceware.org/pipermail/libc-alpha/2020-July/115628.html
[2] https://twitter.com/jomarnz/status/1278043085151309835
    John Marshall:
    Thanks much and sorry for cheating by asking you here on twitter!
    Had a colleague naysaying POSIX’s random() description because of
    what it said in his stdlib.h, so it’s good to fix even this minor
    documentation.
    https://twitter.com/CarlosODonell/status/1278056404029407235
    Carlos O'Donell:
    I want new contributors to have a positive experience. I can only
    do that if I review and accept patches. Thank you for reaching out.
    It is absolutely not cheating :-)

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
"Carlos O'Donell" <[hidden email]> writes:
> A group of people have identified problematic language.

Was this a group of people who felt unwelcome in the glibc community?
Or are we acting without direct information again?  I recall the abort
joke discussion that included only two women (eventually) among the
dozens of men, is this a similar case where only the welcome people are
choosing what "welcome" means?

So far I've seen zero input from someone *actually* affected by this,
and anecdotally *one* who felt harmed by it:

https://lore.kernel.org/git/e198b1a5-e104-d0e5-8904-37ce3937316d@.../

This is not enough information to make a long-lasting decision with.  Or
do we have some hidden data that actually originated from the relevent
demographics?  If so, let's get it out in the open so we can make an
informed decision instead of just another case of the majority ruling
for the minority.

> Problematic language will *never end* and it will always be our
> responsibility to listen to people who are impacted by such
> language ...

Then let's hear from *those* people.  We, the old white male majority,
have done a terrible job in the past; we should not be allowed to make
these decisions on behalf of others any more.

(note: I don't feel strongly about the actual words, they're just words,
you can rename the master branch "platypus" for all I care.  I feel
strongly about engineers making choices based on uninformed emotional
beliefs instead of hard data.)

Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Paul Eggert
On 7/1/20 10:45 AM, DJ Delorie via Libc-alpha wrote:
> I recall the abort
> joke discussion that included only two women (eventually) among the
> dozens of men, is this a similar case where only the welcome people are
> choosing what "welcome" means?

I also recall that discussion, where I was struck by this eloquent email from
Rey Tucker:

https://sourceware.org/pipermail/libc-alpha/2018-May/093595.html

which ended with, "I would bolster this with my credentials as a part of the
glibc community, but history is littered with the ruined husks of tech careers
of the women who dared to challenge the opinions of men, and I really need to
pay my rent and finish a release."

I was the only one to respond to that email directly on the list. I thanked her
for her comment and wrote, "I hope RMS takes time to read and consider your full
comment carefully." Nobody else responded directly, and RMS's eventual reaction
was exceedingly negative.

So much for our being "welcoming", huh?

>> Problematic language will *never end* and it will always be our
>> responsibility to listen to people who are impacted by such
>> language ...
>
> Then let's hear from *those* people.

"*those* people"? I suggest reading Rey Tucker's email again, and try looking at
things from the point of view of "*those* people".
Reply | Threaded
Open this post in threaded view
|

Re: Rename "master" branch to "main"?

Sourceware - libc-alpha mailing list
Paul Eggert <[hidden email]> writes:
> and try looking at things from the point of view of "*those* people".

That would be fantastic, but I admit I'm unqualified.

123