Rename "master" branch to "main"?

Rename "master" branch to "main"?

[Carlos O'Donell]

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.

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.

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

[Carlos O'Donell]

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.

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).

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

[Florian Weimer]

* 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

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

[Carlos O'Donell]

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.

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

[Florian Weimer]

* 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

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

[Richard Earnshaw]

On 30/06/2020 19:59, Florian Weimer via Libc-alpha 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.
> 
> Thanks,
> Florian
> 

And what about all the tracking branches people have that are currently
tracking 'master'?  Will they automatically switch to tracking 'main'?
I doubt it.

IMO this is make-work.

R.

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

[Carlos O'Donell]

On 7/3/20 11:26 AM, Richard Earnshaw wrote:
> On 30/06/2020 19:59, Florian Weimer via Libc-alpha 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.
>>
>> Thanks,
>> Florian
>>
> 
> And what about all the tracking branches people have that are currently
> tracking 'master'?  Will they automatically switch to tracking 'main'?
> I doubt it.

As I noted in my original email the proposal is not to rename existing
historical branches, but to change things going forward.

-- 
Cheers,
Carlos.

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

[Joseph Myers]

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
joseph@codesourcery.com

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

[Carlos O'Donell]

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.

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
joseph@codesourcery.com

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

[DJ Delorie]

"Carlos O'Donell via Libc-alpha" <libc-alpha@sourceware.org> 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

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

[Andreas Schwab]

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, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Carlos O'Donell]

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.

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

[Adhemerval Zanella]

On 30/06/2020 19:59, DJ Delorie via Libc-alpha wrote:
> "Carlos O'Donell via Libc-alpha" <libc-alpha@sourceware.org> 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
> 

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

[Carlos O'Donell]

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" <libc-alpha@sourceware.org> 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.

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

[Adhemerval Zanella]

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" <libc-alpha@sourceware.org> 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.

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

[Carlos O'Donell]

On 6/30/20 6:59 PM, DJ Delorie wrote:
> "Carlos O'Donell via Libc-alpha" <libc-alpha@sourceware.org> 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 :-)

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

[DJ Delorie]

"Carlos O'Donell" <carlos@redhat.com> 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@gmail.com/

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.)

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".

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

[DJ Delorie]

Paul Eggert <eggert@cs.ucla.edu> writes:
> and try looking at things from the point of view of "*those* people".

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

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

[Zack Weinberg]

On Tue, Jun 30, 2020 at 2:10 PM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> 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

I think this is an appropriate change for us to make, and that the
existing requests for other organizations to make this or a similar
change are sufficient evidence for us to do so as well.  We do not
need to know that someone who might contribute to *this project* was
put off by the name "master"; we do know that people have been put off
by Git's use of that name, in other contexts, enough to speak up in
those contexts.  Changing it before we are specifically asked shows
that we are paying attention to these issues as they arise in the
larger community.

That said I think this is not as important as other, similar, changes
we could make.  For instance, the term "master" is used _along with_
"slave" in manual/terminal.texi, and I fully intend to rewrite that
chapter to eliminate that terminology as soon as I find the time.
Anyone want to beat me to it?

zw

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

[Florian Weimer]

* Zack Weinberg:

> That said I think this is not as important as other, similar, changes
> we could make.  For instance, the term "master" is used _along with_
> "slave" in manual/terminal.texi, and I fully intend to rewrite that
> chapter to eliminate that terminology as soon as I find the time.
> Anyone want to beat me to it?

We need some term that starts with “s”, to maintain the connection with
/dev/pts and ptsname (and maybe others).  So far, I've come up with
“surface”, because that's where terminal data is written and read.  It
certainly seems more descriptive than “slave”.  But perhaps there is a
better alternative.

Thanks,
Florian

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

[Joseph Myers]

On Thu, 2 Jul 2020, Zack Weinberg wrote:

> That said I think this is not as important as other, similar, changes
> we could make.  For instance, the term "master" is used _along with_
> "slave" in manual/terminal.texi, and I fully intend to rewrite that
> chapter to eliminate that terminology as soon as I find the time.

Are you going to propose different terms for the next revision of POSIX 
(the first draft of issue 8 was recently released for review, but it's 
still at an early stage of development, with major changes such as 
alignment with the current version of the C standard yet to come, so there 
should be time to include such a change)?  People need to be able to match 
terminology used in GNU documentation with that used in external 
documentation.  In the short term that means we need to state what the 
corresponding POSIX terminology is.  In the longer term, it would clearly 
be desirable for POSIX and GNU to have the same new terminology for 
referring to pseudo-terminals, rather than for them to pick different 
terminology independently.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Paul Eggert]

On 7/2/20 9:36 AM, Joseph Myers wrote:
> Are you going to propose different terms for the next revision of POSIX 

Obvious alternatives are "main" and "subsidiary", which preserve the initial "m"
and "s" needed for consistency with *ptm* and *pts*. If you like, I could
propose something along these lines for POSIX.

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

[Zack Weinberg]

On Thu, Jul 2, 2020 at 12:36 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 2 Jul 2020, Zack Weinberg wrote:
>
> > That said I think this is not as important as other, similar, changes
> > we could make. For instance, the term "master" is used _along with_
> > "slave" in manual/terminal.texi, and I fully intend to rewrite that
> > chapter to eliminate that terminology as soon as I find the time.
>
> Are you going to propose different terms for the next revision of POSIX

I certainly could, although I'd rather rewrite our manual first,
because that'll make it clearer whether the new terms are good.
(I haven't proposed such a cross-cutting change to POSIX before;
what's the best way to find all the uses of terms that need to be
changed?)

> In the short term that means we need to state what the corresponding
> POSIX terminology is. In the longer term, it would clearly be
> desirable for POSIX and GNU to have the same new terminology for
> referring to pseudo-terminals, rather than for them to pick
> different terminology independently.

Agreed. This is a case where I think it *would* be appropriate for the
GNU documentation to editorialize a little -- perhaps a footnote along
the lines of "'X' and 'Y' are referred to as 'master' and 'slave' in
many other documents on this topic. We think this terminology does not
describe the actual relationship between the two sides of a
pseudoterminal accurately, and is also in questionable taste, so we
use 'X' and 'Y' instead." (where 'X' and 'Y' are whatever terms we
pick--I'll send a separate message about that).

(I distinctly recall some GNU or FSF document discouraging the use
of "illegal" to describe input validation errors, so this is not an
unprecedented thing for us to be taking sides on, incidentally.)

zw

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

[Michael Kerrisk]

> That said I think this is not as important as other, similar, changes
> we could make.  For instance, the term "master" is used _along with_
> "slave" in manual/terminal.texi, and I fully intend to rewrite that
> chapter to eliminate that terminology as soon as I find the time.
> Anyone want to beat me to it?

No, but please include me in the discussions. It would be good if libc
and man-pages could find common terminology.

But I agree also with Joseph that the scope is wider and we should
think about what terminology POSIX might (be convinced to) switch to.

Unlike Florian, I'm not excessively attached to the need to settle on
a name that starts with 's'. I think it might be too easy to get into
knots trying to find names that match 'm' and 's', and one should at
least allow for the possibility of good names that don't fit with
those letters; what would be best, IMO, is names that "feel right".
That said, Paul's mail landed while I was composing this, and I find
"main" and "subsidiary" are not awful as ideas, though "main" feels a
little contrived.

Thanks,

Michael

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

[Carlos O'Donell]

On 7/2/20 4:58 PM, Michael Kerrisk wrote:
>> That said I think this is not as important as other, similar, changes
>> we could make.  For instance, the term "master" is used _along with_
>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
>> chapter to eliminate that terminology as soon as I find the time.
>> Anyone want to beat me to it?
> 
> No, but please include me in the discussions. It would be good if libc
> and man-pages could find common terminology.
> 
> But I agree also with Joseph that the scope is wider and we should
> think about what terminology POSIX might (be convinced to) switch to.
> 
> Unlike Florian, I'm not excessively attached to the need to settle on
> a name that starts with 's'. I think it might be too easy to get into
> knots trying to find names that match 'm' and 's', and one should at
> least allow for the possibility of good names that don't fit with
> those letters; what would be best, IMO, is names that "feel right".
> That said, Paul's mail landed while I was composing this, and I find
> "main" and "subsidiary" are not awful as ideas, though "main" feels a
> little contrived.

I agree. It is an auto-proposition that the letters ptm/pts actually
match the terminology used. You can retrofit the acronym if *any* of
the letters are used in the right order.

-- 
Cheers,
Carlos.

Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Zack Weinberg]

On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>
> > That said I think this is not as important as other, similar, changes
> > we could make. For instance, the term "master" is used _along with_
> > "slave" in manual/terminal.texi, and I fully intend to rewrite that
> > chapter to eliminate that terminology as soon as I find the time.
> > Anyone want to beat me to it?
>
> No, but please include me in the discussions. It would be good if libc
> and man-pages could find common terminology.
>
> But I agree also with Joseph that the scope is wider and we should
> think about what terminology POSIX might (be convinced to) switch to.
>
> Unlike Florian, I'm not excessively attached to the need to settle on
> a name that starts with 's'. I think it might be too easy to get into
> knots trying to find names that match 'm' and 's', and one should at
> least allow for the possibility of good names that don't fit with
> those letters; what would be best, IMO, is names that "feel right".

I agree.  In particular I think there is no reason to struggle with
coming up with terms that fit "ptmx" and "pts" because BSD ptys use
totally different device node names anyway (tty[pqrs...]NN and
pty[pqrs...]NN) and there's no hope of finding something that works
with both.

I don't want to commit to terminology until I've had a go at rewriting
the manual, because I think doing the rewrite will be the easiest way
to figure out whether the new terms are good, but what I'm currently
thinking is:

    "pty master device" -> "pty line-side device" or "outside device"
    "pty slave device"  -> "pty host-side device" or "inside device"
    /dev/ptmx stands for "pseudoterminal multiplexer"
    /dev/pts  stand for "pseudoterminals (directory of)"

Currently I like "line-side" and "host-side" because it seems like a
natural generalization from true terminal device nodes (which are
always host-side) to pseudoterminals (additionally have a line-side
device node).  And it can generalize to the relationship between
Linux's /dev/ttyNN and /dev/vcs(a)NN as well.

zw

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[J William Piggott]

On Sat, 4 Jul 2020, Zack Weinberg wrote:

> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>
>>> That said I think this is not as important as other, similar, changes
>>> we could make. For instance, the term "master" is used _along with_
>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
>>> chapter to eliminate that terminology as soon as I find the time.
>>> Anyone want to beat me to it?
>>
>> No, but please include me in the discussions. It would be good if libc
>> and man-pages could find common terminology.
>>
>> But I agree also with Joseph that the scope is wider and we should
>> think about what terminology POSIX might (be convinced to) switch to.
>>
>> Unlike Florian, I'm not excessively attached to the need to settle on
>> a name that starts with 's'. I think it might be too easy to get into
>> knots trying to find names that match 'm' and 's', and one should at
>> least allow for the possibility of good names that don't fit with
>> those letters; what would be best, IMO, is names that "feel right".
>
> I agree.  In particular I think there is no reason to struggle with
> coming up with terms that fit "ptmx" and "pts" because BSD ptys use
> totally different device node names anyway (tty[pqrs...]NN and
> pty[pqrs...]NN) and there's no hope of finding something that works
> with both.
>
> I don't want to commit to terminology until I've had a go at rewriting
> the manual, because I think doing the rewrite will be the easiest way
> to figure out whether the new terms are good, but what I'm currently
> thinking is:
>
>    "pty master device" -> "pty line-side device" or "outside device"
>    "pty slave device"  -> "pty host-side device" or "inside device"
>    /dev/ptmx stands for "pseudoterminal multiplexer"
>    /dev/pts  stand for "pseudoterminals (directory of)"
>
> Currently I like "line-side" and "host-side" because it seems like a
> natural generalization from true terminal device nodes (which are
> always host-side) to pseudoterminals (additionally have a line-side
> device node).  And it can generalize to the relationship between
> Linux's /dev/ttyNN and /dev/vcs(a)NN as well.

I'm not sure that line-side would be quickly relatable. Perhaps even
ambiguous, as both ends have a line-side. Online, both ends are hosts as
far as that goes. In old terms only one end was a 'terminal'; the other
end was the mainframe, right?

If we want to evoke online terminals of old; there are well
established, and quickly relatable, terms from the Internet.

server <-> client

Or the 'agent' terms from email; substitute (T)erminal for (M)ail, for
example, TUA Terminal User Agent:

MUA: Mail User Agent (client)
MTA: Mail Transfer Agent (server)
  Or
MDA: Mail Distribution Agent
MSA: Mail Submission Agent


>
> zw
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Michael Kerrisk (man-pages)]

On Sun, 5 Jul 2020 at 16:55, J William Piggott <elseifthen@gmx.com> wrote:
>
>
>
> On Sat, 4 Jul 2020, Zack Weinberg wrote:
>
> > On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com> wrote:
> >
> > I don't want to commit to terminology until I've had a go at rewriting
> > the manual, because I think doing the rewrite will be the easiest way
> > to figure out whether the new terms are good, but what I'm currently
> > thinking is:
> >
> >    "pty master device" -> "pty line-side device" or "outside device"
> >    "pty slave device"  -> "pty host-side device" or "inside device"
> >    /dev/ptmx stands for "pseudoterminal multiplexer"
> >    /dev/pts  stand for "pseudoterminals (directory of)"
> >
> > Currently I like "line-side" and "host-side" because it seems like a
> > natural generalization from true terminal device nodes (which are
> > always host-side) to pseudoterminals (additionally have a line-side
> > device node).  And it can generalize to the relationship between
> > Linux's /dev/ttyNN and /dev/vcs(a)NN as well.
>
> I'm not sure that line-side would be quickly relatable. Perhaps even
> ambiguous, as both ends have a line-side. Online, both ends are hosts as
> far as that goes. In old terms only one end was a 'terminal'; the other
> end was the mainframe, right?
>
> If we want to evoke online terminals of old; there are well
> established, and quickly relatable, terms from the Internet.
>
> server <-> client
>
> Or the 'agent' terms from email; substitute (T)erminal for (M)ail, for
> example, TUA Terminal User Agent:
>
> MUA: Mail User Agent (client)
> MTA: Mail Transfer Agent (server)
>   Or
> MDA: Mail Distribution Agent
> MSA: Mail Submission Agent

FWIW, "server" + "client" feels too tied to network applications for
my taste (and many applications of pseudoterminals have no relation to
networks). But still, I think it's good to kickk ideas like this
around.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Michael Kerrisk (man-pages)]

Hello Zack.

On 7/4/20 6:52 PM, Zack Weinberg wrote:
> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>
>>> That said I think this is not as important as other, similar, changes
>>> we could make. For instance, the term "master" is used _along with_
>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
>>> chapter to eliminate that terminology as soon as I find the time.
>>> Anyone want to beat me to it?
>>
>> No, but please include me in the discussions. It would be good if libc
>> and man-pages could find common terminology.
>>
>> But I agree also with Joseph that the scope is wider and we should
>> think about what terminology POSIX might (be convinced to) switch to.
>>
>> Unlike Florian, I'm not excessively attached to the need to settle on
>> a name that starts with 's'. I think it might be too easy to get into
>> knots trying to find names that match 'm' and 's', and one should at
>> least allow for the possibility of good names that don't fit with
>> those letters; what would be best, IMO, is names that "feel right".
> 
> I agree.  In particular I think there is no reason to struggle with
> coming up with terms that fit "ptmx" and "pts" because BSD ptys use
> totally different device node names anyway (tty[pqrs...]NN and
> pty[pqrs...]NN) and there's no hope of finding something that works
> with both.

(Good point.)

> I don't want to commit to terminology until I've had a go at rewriting
> the manual, because I think doing the rewrite will be the easiest way
> to figure out whether the new terms are good, 

I think that's a good text engineering approach. I think it's fine
to cycle through a number of ideas, rejecting them until something feels
"right".

> but what I'm currently
> thinking is:
> 
>     "pty master device" -> "pty line-side device" or "outside device"
>     "pty slave device"  -> "pty host-side device" or "inside device"
>     /dev/ptmx stands for "pseudoterminal multiplexer"
>     /dev/pts  stand for "pseudoterminals (directory of)"
> 
> Currently I like "line-side" and "host-side" because it seems like a
> natural generalization from true terminal device nodes (which are
> always host-side) to pseudoterminals (additionally have a line-side
> device node).  And it can generalize to the relationship between
> Linux's /dev/ttyNN and /dev/vcs(a)NN as well.

So far, "line-side" and "host-side" don't do it for me. But maybe
I just need time to sit with those terms to get used to them.

As we consider names, I think it's good to keep in mind the rather
diverse set of applications where pseudoterminals are used, including

ssh etc.
xterm etc.
expect
tmux
script
unbuffer

I just throw out some ideas (in the order master, slave):

"driver" device plus "terminal" device
"driver" device plus "client" device
"proxy" device plus "terminal" device
"proxy" device plus "client" device

I'm not arguing that these are better than your terms. (At least, 
not yet ;-).) But I think it's useful to throw a lot of ideas into
the mix, in the hope of sparking further ideas from others.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Michael Kerrisk (man-pages)]

[I'm just threading Elliot into this discussion, because he works on Android
and has an interest in finding also better terminology here. <EOM>]

On 7/6/20 11:13 AM, Michael Kerrisk (man-pages) wrote:
> Hello Zack.
> 
> On 7/4/20 6:52 PM, Zack Weinberg wrote:
>> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>>
>>>> That said I think this is not as important as other, similar, changes
>>>> we could make. For instance, the term "master" is used _along with_
>>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
>>>> chapter to eliminate that terminology as soon as I find the time.
>>>> Anyone want to beat me to it?
>>>
>>> No, but please include me in the discussions. It would be good if libc
>>> and man-pages could find common terminology.
>>>
>>> But I agree also with Joseph that the scope is wider and we should
>>> think about what terminology POSIX might (be convinced to) switch to.
>>>
>>> Unlike Florian, I'm not excessively attached to the need to settle on
>>> a name that starts with 's'. I think it might be too easy to get into
>>> knots trying to find names that match 'm' and 's', and one should at
>>> least allow for the possibility of good names that don't fit with
>>> those letters; what would be best, IMO, is names that "feel right".
>>
>> I agree.  In particular I think there is no reason to struggle with
>> coming up with terms that fit "ptmx" and "pts" because BSD ptys use
>> totally different device node names anyway (tty[pqrs...]NN and
>> pty[pqrs...]NN) and there's no hope of finding something that works
>> with both.
> 
> (Good point.)
> 
>> I don't want to commit to terminology until I've had a go at rewriting
>> the manual, because I think doing the rewrite will be the easiest way
>> to figure out whether the new terms are good, 
> 
> I think that's a good text engineering approach. I think it's fine
> to cycle through a number of ideas, rejecting them until something feels
> "right".
> 
>> but what I'm currently
>> thinking is:
>>
>>     "pty master device" -> "pty line-side device" or "outside device"
>>     "pty slave device"  -> "pty host-side device" or "inside device"
>>     /dev/ptmx stands for "pseudoterminal multiplexer"
>>     /dev/pts  stand for "pseudoterminals (directory of)"
>>
>> Currently I like "line-side" and "host-side" because it seems like a
>> natural generalization from true terminal device nodes (which are
>> always host-side) to pseudoterminals (additionally have a line-side
>> device node).  And it can generalize to the relationship between
>> Linux's /dev/ttyNN and /dev/vcs(a)NN as well.
> 
> So far, "line-side" and "host-side" don't do it for me. But maybe
> I just need time to sit with those terms to get used to them.
> 
> As we consider names, I think it's good to keep in mind the rather
> diverse set of applications where pseudoterminals are used, including
> 
> ssh etc.
> xterm etc.
> expect
> tmux
> script
> unbuffer
> 
> I just throw out some ideas (in the order master, slave):
> 
> "driver" device plus "terminal" device
> "driver" device plus "client" device
> "proxy" device plus "terminal" device
> "proxy" device plus "client" device
> 
> I'm not arguing that these are better than your terms. (At least, 
> not yet ;-).) But I think it's useful to throw a lot of ideas into
> the mix, in the hope of sparking further ideas from others.
> 
> Cheers,
> 
> Michael
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Mon, Jul 27, 2020 at 1:32 PM Michael Kerrisk (man-pages) <
mtk.manpages@gmail.com> wrote:

> [I'm just threading Elliot into this discussion, because he works on
> Android
> and has an interest in finding also better terminology here. <EOM>]
>
> On 7/6/20 11:13 AM, Michael Kerrisk (man-pages) wrote:
> > Hello Zack.
> >
> > On 7/4/20 6:52 PM, Zack Weinberg wrote:
> >> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com>
> wrote:
> >>>
> >>>> That said I think this is not as important as other, similar, changes
> >>>> we could make. For instance, the term "master" is used _along with_
> >>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
> >>>> chapter to eliminate that terminology as soon as I find the time.
> >>>> Anyone want to beat me to it?
> >>>
> >>> No, but please include me in the discussions. It would be good if libc
> >>> and man-pages could find common terminology.
> >>>
> >>> But I agree also with Joseph that the scope is wider and we should
> >>> think about what terminology POSIX might (be convinced to) switch to.
> >>>
> >>> Unlike Florian, I'm not excessively attached to the need to settle on
> >>> a name that starts with 's'. I think it might be too easy to get into
> >>> knots trying to find names that match 'm' and 's', and one should at
> >>> least allow for the possibility of good names that don't fit with
> >>> those letters; what would be best, IMO, is names that "feel right".
> >>
> >> I agree.  In particular I think there is no reason to struggle with
> >> coming up with terms that fit "ptmx" and "pts" because BSD ptys use
> >> totally different device node names anyway (tty[pqrs...]NN and
> >> pty[pqrs...]NN) and there's no hope of finding something that works
> >> with both.
> >
> > (Good point.)
> >
> >> I don't want to commit to terminology until I've had a go at rewriting
> >> the manual, because I think doing the rewrite will be the easiest way
> >> to figure out whether the new terms are good,
> >
> > I think that's a good text engineering approach. I think it's fine
> > to cycle through a number of ideas, rejecting them until something feels
> > "right".
> >
> >> but what I'm currently
> >> thinking is:
> >>
> >>     "pty master device" -> "pty line-side device" or "outside device"
> >>     "pty slave device"  -> "pty host-side device" or "inside device"
> >>     /dev/ptmx stands for "pseudoterminal multiplexer"
> >>     /dev/pts  stand for "pseudoterminals (directory of)"
>

fwiw, until the topic came up recently, i'd believed since the 1990s that
that's /dev/ptmx and /dev/pts stood for anyway: multiplexer and a plural.


> >> Currently I like "line-side" and "host-side" because it seems like a
> >> natural generalization from true terminal device nodes (which are
> >> always host-side) to pseudoterminals (additionally have a line-side
> >> device node).  And it can generalize to the relationship between
> >> Linux's /dev/ttyNN and /dev/vcs(a)NN as well.
> >
> > So far, "line-side" and "host-side" don't do it for me. But maybe
> > I just need time to sit with those terms to get used to them.


yeah, i'm can't say i'm particularly excited about those terms ... but
"master" and "slave" weren't super obvious either.

tbh, i don't think any of the choices in this thread are actually _worse_
in terms of clarity (though existing practice was at least consistent so
you could rtfm).

i found the python reference i failed to find for michael earlier... it
looks like i couldn't find it because it's the one master/slave change to
python that they didn't actually submit. in
https://github.com/python/cpython/pull/9100 they were going to go with
parent and child but gvanrossum said they shouldn't change unless Unix
changes.

at least parent/child are names that most folks (including non-native
speakers) will have had to learn already.

golang went with pty/tty (
https://github.com/creack/pty/commit/7dc38fb350b1d71383eed149e73acb7bae231ddb)
which is interestingly simple.


>
>
> As we consider names, I think it's good to keep in mind the rather
> > diverse set of applications where pseudoterminals are used, including
> >
> > ssh etc.
>

there was some trolling about the commit on the openbsd mailing list which
is why i've seen it, but afaict they've only renamed blacklist/whitelist so
far.


> > xterm etc.
> > expect
> > tmux
> > script
> > unbuffer
> >
> > I just throw out some ideas (in the order master, slave):
> >
> > "driver" device plus "terminal" device
> > "driver" device plus "client" device
> > "proxy" device plus "terminal" device
> > "proxy" device plus "client" device
> >
> > I'm not arguing that these are better than your terms. (At least,
> > not yet ;-).) But I think it's useful to throw a lot of ideas into
> > the mix, in the hope of sparking further ideas from others.
> >
> > Cheers,
> >
> > Michael
> >
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Mon, Jul 27, 2020 at 1:52 PM enh <enh@google.com> wrote:

>
>
> On Mon, Jul 27, 2020 at 1:32 PM Michael Kerrisk (man-pages) <
> mtk.manpages@gmail.com> wrote:
>
>> [I'm just threading Elliot into this discussion, because he works on
>> Android
>> and has an interest in finding also better terminology here. <EOM>]
>>
>> On 7/6/20 11:13 AM, Michael Kerrisk (man-pages) wrote:
>> > Hello Zack.
>> >
>> > On 7/4/20 6:52 PM, Zack Weinberg wrote:
>> >> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com>
>> wrote:
>> >>>
>> >>>> That said I think this is not as important as other, similar, changes
>> >>>> we could make. For instance, the term "master" is used _along with_
>> >>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
>> >>>> chapter to eliminate that terminology as soon as I find the time.
>> >>>> Anyone want to beat me to it?
>> >>>
>> >>> No, but please include me in the discussions. It would be good if libc
>> >>> and man-pages could find common terminology.
>> >>>
>> >>> But I agree also with Joseph that the scope is wider and we should
>> >>> think about what terminology POSIX might (be convinced to) switch to.
>> >>>
>> >>> Unlike Florian, I'm not excessively attached to the need to settle on
>> >>> a name that starts with 's'. I think it might be too easy to get into
>> >>> knots trying to find names that match 'm' and 's', and one should at
>> >>> least allow for the possibility of good names that don't fit with
>> >>> those letters; what would be best, IMO, is names that "feel right".
>> >>
>> >> I agree.  In particular I think there is no reason to struggle with
>> >> coming up with terms that fit "ptmx" and "pts" because BSD ptys use
>> >> totally different device node names anyway (tty[pqrs...]NN and
>> >> pty[pqrs...]NN) and there's no hope of finding something that works
>> >> with both.
>> >
>> > (Good point.)
>> >
>> >> I don't want to commit to terminology until I've had a go at rewriting
>> >> the manual, because I think doing the rewrite will be the easiest way
>> >> to figure out whether the new terms are good,
>> >
>> > I think that's a good text engineering approach. I think it's fine
>> > to cycle through a number of ideas, rejecting them until something feels
>> > "right".
>> >
>> >> but what I'm currently
>> >> thinking is:
>> >>
>> >>     "pty master device" -> "pty line-side device" or "outside device"
>> >>     "pty slave device"  -> "pty host-side device" or "inside device"
>> >>     /dev/ptmx stands for "pseudoterminal multiplexer"
>> >>     /dev/pts  stand for "pseudoterminals (directory of)"
>>
>
> fwiw, until the topic came up recently, i'd believed since the 1990s that
> that's /dev/ptmx and /dev/pts stood for anyway: multiplexer and a plural.
>
>
>> >> Currently I like "line-side" and "host-side" because it seems like a
>> >> natural generalization from true terminal device nodes (which are
>> >> always host-side) to pseudoterminals (additionally have a line-side
>> >> device node).  And it can generalize to the relationship between
>> >> Linux's /dev/ttyNN and /dev/vcs(a)NN as well.
>> >
>> > So far, "line-side" and "host-side" don't do it for me. But maybe
>> > I just need time to sit with those terms to get used to them.
>
>
> yeah, i'm can't say i'm particularly excited about those terms ... but
> "master" and "slave" weren't super obvious either.
>
> tbh, i don't think any of the choices in this thread are actually _worse_
> in terms of clarity (though existing practice was at least consistent so
> you could rtfm).
>
> i found the python reference i failed to find for michael earlier... it
> looks like i couldn't find it because it's the one master/slave change to
> python that they didn't actually submit. in
> https://github.com/python/cpython/pull/9100 they were going to go with
> parent and child but gvanrossum said they shouldn't change unless Unix
> changes.
>
> at least parent/child are names that most folks (including non-native
> speakers) will have had to learn already.
>
> golang went with pty/tty (
> https://github.com/creack/pty/commit/7dc38fb350b1d71383eed149e73acb7bae231ddb)
> which is interestingly simple.
>
>
>>
>>
> > As we consider names, I think it's good to keep in mind the rather
>> > diverse set of applications where pseudoterminals are used, including
>> >
>> > ssh etc.
>>
>
> there was some trolling about the commit on the openbsd mailing list which
> is why i've seen it, but afaict they've only renamed blacklist/whitelist so
> far.
>

actually, being a little less lazy and actually looking at the source, i
see openssh was already using pty and tty, which is what golang has
switched to.

if it wasn't for my desire to match the man page, i'd be sold on pty/tty at
this point --- direct, inoffensive, and no new words for non-native
speakers to learn :-)


> > xterm etc.
>> > expect
>> > tmux
>> > script
>> > unbuffer
>> >
>> > I just throw out some ideas (in the order master, slave):
>> >
>> > "driver" device plus "terminal" device
>> > "driver" device plus "client" device
>> > "proxy" device plus "terminal" device
>> > "proxy" device plus "client" device
>> >
>> > I'm not arguing that these are better than your terms. (At least,
>> > not yet ;-).) But I think it's useful to throw a lot of ideas into
>> > the mix, in the hope of sparking further ideas from others.
>> >
>> > Cheers,
>> >
>> > Michael
>> >
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
>>
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Florian Weimer]

> if it wasn't for my desire to match the man page, i'd be sold on
> pty/tty at this point --- direct, inoffensive, and no new words for
> non-native speakers to learn :-)

Is the use of tty in this context compatible with non-UNIX98 terminals?
(Not sure if BSD still uses them.  Hurd apparently does.)

Thanks,
Florian

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Mon, Jul 27, 2020 at 2:00 PM Florian Weimer <fweimer@redhat.com> wrote:

> > if it wasn't for my desire to match the man page, i'd be sold on
> > pty/tty at this point --- direct, inoffensive, and no new words for
> > non-native speakers to learn :-)
>
> Is the use of tty in this context compatible with non-UNIX98 terminals?
> (Not sure if BSD still uses them.  Hurd apparently does.)
>

the golang BSD support uses pty/tty, and openssh is from the openbsd
folks, so they don't seem to care.

i couldn't find anything about hurd ttys from an internet search, although
it does look like even they're using the pty/tty names for the device files?


> Thanks,
> Florian
>
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Michael Kerrisk (man-pages)]

On 7/27/20 10:52 PM, enh wrote:

[...]

> yeah, i'm can't say i'm particularly excited about those terms ... but
> "master" and "slave" weren't super obvious either.
> 
> tbh, i don't think any of the choices in this thread are actually _worse_
> in terms of clarity (though existing practice was at least consistent so
> you could rtfm).
> 
> i found the python reference i failed to find for michael earlier... it
> looks like i couldn't find it because it's the one master/slave change to
> python that they didn't actually submit. in
> https://github.com/python/cpython/pull/9100 they were going to go with
> parent and child but gvanrossum said they shouldn't change unless Unix
> changes.
> 
> at least parent/child are names that most folks (including non-native
> speakers) will have had to learn already.

Those names (parent, child) do seem strange to me. With process
creation, those terms make a kind of sense. There's no obvious sense
to me for parent/child in the pty context. (The nearest I can see: The
parent device tells the child device what to do? Now that's a whole 
other interesting can of worms.)

> golang went with pty/tty (
> https://github.com/creack/pty/commit/7dc38fb350b1d71383eed149e73acb7bae231ddb)
> which is interestingly simple.

The simplicity of it is appealing. But, how does this read in
prose documentation. Do we replace actual English words with 
abbreviations ("pty", "tty")? That looks a little weird in writing, 
and seems weirder when spoken aloud. And then: "the pseudoterminal
pty device" seems a little bit like something I might find in
"The Department of Redundancy Dept"...

I think proper English nouns would be preferable, if we can find
ones that are suitable.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Florian Weimer]

* Michael Kerrisk:

> Those names (parent, child) do seem strange to me. With process
> creation, those terms make a kind of sense.

Not really: it's rare that a subprocess does not exit before the process
that launched it.

> The simplicity of it is appealing. But, how does this read in
> prose documentation. Do we replace actual English words with 
> abbreviations ("pty", "tty")? That looks a little weird in writing, 
> and seems weirder when spoken aloud. And then: "the pseudoterminal
> pty device" seems a little bit like something I might find in
> "The Department of Redundancy Dept"...

Maybe we can use “pseudoterminal device” and “terminal device”?

Thanks,
Florian

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Tue, Jul 28, 2020, 08:33 Florian Weimer <fweimer@redhat.com> wrote:

> * Michael Kerrisk:
>
> > Those names (parent, child) do seem strange to me. With process
> > creation, those terms make a kind of sense.
>
> Not really: it's rare that a subprocess does not exit before the process
> that launched it.
>
> > The simplicity of it is appealing. But, how does this read in
> > prose documentation. Do we replace actual English words with
> > abbreviations ("pty", "tty")? That looks a little weird in writing,
> > and seems weirder when spoken aloud. And then: "the pseudoterminal
> > pty device" seems a little bit like something I might find in
> > "The Department of Redundancy Dept"...
>
> Maybe we can use “pseudoterminal device” and “terminal device”?
>

Yeah, that's the style the go docs use.

Btw, as for other popular languages, Swift doesn't seem to have its own
API, and just has you call libc directly. Rust too, afaict. And there's no
corresponding Java API at all, you have to use JNI.

Thanks,
> Florian
>
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Michael Kerrisk (man-pages)]

On 7/28/20 5:32 PM, Florian Weimer wrote:
> * Michael Kerrisk:
> 
>> Those names (parent, child) do seem strange to me. With process
>> creation, those terms make a kind of sense.
> 
> Not really: it's rare that a subprocess does not exit before the process
> that launched it.
> 
>> The simplicity of it is appealing. But, how does this read in
>> prose documentation. Do we replace actual English words with 
>> abbreviations ("pty", "tty")? That looks a little weird in writing, 
>> and seems weirder when spoken aloud. And then: "the pseudoterminal
>> pty device" seems a little bit like something I might find in
>> "The Department of Redundancy Dept"...
> 
> Maybe we can use “pseudoterminal device” and “terminal device”?

So, the proposed terminology would be:

* pseudoterminal device pair
* pseudoterminal device (formerly: master)
* terminal device (formerly: slave)

?

It's an interesting idea. I like the concept, but I'd want to
see how it looks in rewritten manual pages. I'll take a look.

Thanks,

MIchael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Tue, Jul 28, 2020 at 12:16 PM Michael Kerrisk (man-pages) <
mtk.manpages@gmail.com> wrote:

> On 7/28/20 5:32 PM, Florian Weimer wrote:
> > * Michael Kerrisk:
> >
> >> Those names (parent, child) do seem strange to me. With process
> >> creation, those terms make a kind of sense.
> >
> > Not really: it's rare that a subprocess does not exit before the process
> > that launched it.
> >
> >> The simplicity of it is appealing. But, how does this read in
> >> prose documentation. Do we replace actual English words with
> >> abbreviations ("pty", "tty")? That looks a little weird in writing,
> >> and seems weirder when spoken aloud. And then: "the pseudoterminal
> >> pty device" seems a little bit like something I might find in
> >> "The Department of Redundancy Dept"...
> >
> > Maybe we can use “pseudoterminal device” and “terminal device”?
>
> So, the proposed terminology would be:
>
> * pseudoterminal device pair
> * pseudoterminal device (formerly: master)
> * terminal device (formerly: slave)
>
> ?
>
> It's an interesting idea. I like the concept, but I'd want to
> see how it looks in rewritten manual pages. I'll take a look.
>

yeah, that will be interesting to see. in the meantime, on the source
side...

trying pty and tty on for size, and rewriting the implementation and tests
just to see how awful it looked... it turns out that the new names work out
really nicely. in particular, you end up passing pty to functions like
grantpt() or ptsname() with a 'p' in the name, and tty to functions like
tcsetattr() and ttyname() that just have 't's.

(https://android-review.googlesource.com/c/platform/bionic/+/1374048 if you
want to see the diffs.)


> Thanks,
>
> MIchael
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Tue, Jul 28, 2020 at 8:26 AM Michael Kerrisk (man-pages) <
mtk.manpages@gmail.com> wrote:

> On 7/27/20 10:52 PM, enh wrote:
>
> [...]
>
> > yeah, i'm can't say i'm particularly excited about those terms ... but
> > "master" and "slave" weren't super obvious either.
> >
> > tbh, i don't think any of the choices in this thread are actually _worse_
> > in terms of clarity (though existing practice was at least consistent so
> > you could rtfm).
> >
> > i found the python reference i failed to find for michael earlier... it
> > looks like i couldn't find it because it's the one master/slave change to
> > python that they didn't actually submit. in
> > https://github.com/python/cpython/pull/9100 they were going to go with
> > parent and child but gvanrossum said they shouldn't change unless Unix
> > changes.
> >
> > at least parent/child are names that most folks (including non-native
> > speakers) will have had to learn already.
>
> Those names (parent, child) do seem strange to me. With process
> creation, those terms make a kind of sense. There's no obvious sense
> to me for parent/child in the pty context. (The nearest I can see: The
> parent device tells the child device what to do? Now that's a whole
> other interesting can of worms.)
>

parent/child might be a good choice for the related forkpty(). (given
bionic's "you'll probably be looking at this in Android Studio or Visual
Studio Code's argument name completion UI, so let's use a longer name to
save you a trip to the man page if you know roughly what you're doing but
can't remember what order the arguments are in" style, that would probably
still be `int forkpty(int* _Nonnull __parent_pty_fd, char* _Nullable
__child_tty_name, ...`.)

(note also that the man page for forkpty() seems to be the only place the
return type is given as pid_t rather than int --- afaict all the libcs
actually use int?)


> > golang went with pty/tty (
> >
> https://github.com/creack/pty/commit/7dc38fb350b1d71383eed149e73acb7bae231ddb
> )
> > which is interestingly simple.
>
> The simplicity of it is appealing. But, how does this read in
> prose documentation. Do we replace actual English words with
> abbreviations ("pty", "tty")? That looks a little weird in writing,
> and seems weirder when spoken aloud. And then: "the pseudoterminal
> pty device" seems a little bit like something I might find in
> "The Department of Redundancy Dept"...
>
> I think proper English nouns would be preferable, if we can find
> ones that are suitable.
>
> Cheers,
>
> Michael
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
>

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[Michael Kerrisk (man-pages)]

On 7/28/20 8:47 PM, enh wrote:
[...]

> parent/child might be a good choice for the related forkpty(). (given
> bionic's "you'll probably be looking at this in Android Studio or Visual
> Studio Code's argument name completion UI, so let's use a longer name to
> save you a trip to the man page if you know roughly what you're doing but
> can't remember what order the arguments are in" style, that would probably
> still be `int forkpty(int* _Nonnull __parent_pty_fd, char* _Nullable
> __child_tty_name, ...`.)
> 
> (note also that the man page for forkpty() seems to be the only place the
> return type is given as pid_t rather than int --- afaict all the libcs
> actually use int?)

The manual page seems to have been lifted (many years ago, before my 
time) from OpenBSD, where the return type really is pid_t.

I wonder what the implications of changing this in glibc are? Or maybe
the manual page just needs to be changed.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh]

On Tue, Jul 28, 2020 at 12:27 PM Michael Kerrisk (man-pages) <
mtk.manpages@gmail.com> wrote:

> On 7/28/20 8:47 PM, enh wrote:
> [...]
>
> > parent/child might be a good choice for the related forkpty(). (given
> > bionic's "you'll probably be looking at this in Android Studio or Visual
> > Studio Code's argument name completion UI, so let's use a longer name to
> > save you a trip to the man page if you know roughly what you're doing but
> > can't remember what order the arguments are in" style, that would
> probably
> > still be `int forkpty(int* _Nonnull __parent_pty_fd, char* _Nullable
> > __child_tty_name, ...`.)
> >
> > (note also that the man page for forkpty() seems to be the only place the
> > return type is given as pid_t rather than int --- afaict all the libcs
> > actually use int?)
>
> The manual page seems to have been lifted (many years ago, before my
> time) from OpenBSD, where the return type really is pid_t.
>

(ah, yes: the other BSDs and macOS too. it's bionic/glibc/musl that all
have int.)


> I wonder what the implications of changing this in glibc are? Or maybe
> the manual page just needs to be changed.
>

(certainly macOS/OpenBSD's forkpty lives in <util.h> and libutil, so the
man page isn't quite right for them either :-) [though NetBSD seems to have
it in pty.h. "if you know one BSD, you know one BSD..."])


> Thanks,
>
> Michael
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
>

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

[Richard Earnshaw]

On 30/06/2020 19:10, Carlos O'Donell via Libc-alpha wrote:
> 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


Why?  What's the justification for this other than to break everybody's
workflow and to make life more difficult for everyone who works on other
projects where master is called 'master'?

R.

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

[Carlos O'Donell]

On 7/3/20 11:22 AM, Richard Earnshaw wrote:
> On 30/06/2020 19:10, Carlos O'Donell via Libc-alpha wrote:
>> 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
> 
> 
> Why?

Do the above links provide enough background regarding the justification?

Are you requesting that I summarize it here?

-- 
Cheers,
Carlos.

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

[Carlos O'Donell]

On 6/30/20 2:10 PM, Carlos O'Donell wrote:
> 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.

The Linux kernel has adopted the following guidance:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

-- 
Cheers,
Carlos.

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On 30 Jun 2020 14:10, Carlos O'Donell via Libc-alpha wrote:
> As we approach the release boundary for 2.32 we come to a natural point
> where we can rename our development and release branch.
> 
> My proposal would be to rename the development and current release branch:
> 
> * master -> main

this seems to have stalled.  we should do this!

i don't think we need to wait on git itself.  even before 2020, many
projects used names other than "master" for branches as their default.
but now as we start 2021, the number of projects that have migrated
has gone up quite a lot, and with GH making it well known to many
people, i think that addresses the "it's confusing" angle.

wrt compatibility, i played around with things a little on my own
server, and it seems that someone with shell access could set up a
redirect:
	$ cat refs/heads/master
	ref: refs/heads/main
pushing to master in this situation will update main.  that should
be a fairly easy way to not break existing checkouts but allowing
the default to switch to "main".  if we consider the number of devs
with write access is low, we can block pushes to "master" and they
would be forced to migrate.  then once people are eased in to the
new state, we can either delete master or freeze it.  either way,
anyone actively pulling from the repo should notice quickly.

bonus points: "main" is shorter to type than "master", and it's
mostly the same amount of tab completion.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Siddhesh Poyarekar]

On 1/14/21 2:51 PM, Mike Frysinger via Libc-alpha wrote:
> this seems to have stalled.  we should do this!
> 
> i don't think we need to wait on git itself.  even before 2020, many
> projects used names other than "master" for branches as their default.
> but now as we start 2021, the number of projects that have migrated
> has gone up quite a lot, and with GH making it well known to many
> people, i think that addresses the "it's confusing" angle.
> 
> wrt compatibility, i played around with things a little on my own
> server, and it seems that someone with shell access could set up a
> redirect:
> 	$ cat refs/heads/master
> 	ref: refs/heads/main
> pushing to master in this situation will update main.  that should
> be a fairly easy way to not break existing checkouts but allowing
> the default to switch to "main".  if we consider the number of devs
> with write access is low, we can block pushes to "master" and they
> would be forced to migrate.  then once people are eased in to the
> new state, we can either delete master or freeze it.  either way,
> anyone actively pulling from the repo should notice quickly.

+1, this seems like a reasonable approach.

> bonus points: "main" is shorter to type than "master", and it's
> mostly the same amount of tab completion.

I like 'trunk' too as a hat tip to the old days (and it works well with 
'branches') but I'm staying away from the bike shed :)

Siddhesh

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

[Joseph Myers]

On Thu, 14 Jan 2021, Mike Frysinger via Libc-alpha wrote:

> On 30 Jun 2020 14:10, Carlos O'Donell via Libc-alpha wrote:
> > As we approach the release boundary for 2.32 we come to a natural point
> > where we can rename our development and release branch.
> > 
> > My proposal would be to rename the development and current release branch:
> > 
> > * master -> main
> 
> this seems to have stalled.  we should do this!

Please see my previous comments.  Anyone making such a change needs to 
review the git hooks, hook configuration (e.g. 
refs/meta/config:project.config), hooks-bin scripts such as 
email-to-bugzilla-filtered and post-receive, and wiki and other 
documentation to identify *all* changes needed where master or branches 
containing the string "master" are special-cased or otherwise mentioned.  
The hooks and hook configuration updates need to be ready in advance of 
such a change.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Carlos O'Donell]

On 1/14/21 12:54 PM, Joseph Myers wrote:
> On Thu, 14 Jan 2021, Mike Frysinger via Libc-alpha wrote:
> 
>> On 30 Jun 2020 14:10, Carlos O'Donell via Libc-alpha wrote:
>>> As we approach the release boundary for 2.32 we come to a natural point
>>> where we can rename our development and release branch.
>>>
>>> My proposal would be to rename the development and current release branch:
>>>
>>> * master -> main
>>
>> this seems to have stalled.  we should do this!
> 
> Please see my previous comments.  Anyone making such a change needs to 
> review the git hooks, hook configuration (e.g. 
> refs/meta/config:project.config), hooks-bin scripts such as 
> email-to-bugzilla-filtered and post-receive, and wiki and other 
> documentation to identify *all* changes needed where master or branches 
> containing the string "master" are special-cased or otherwise mentioned.  
> The hooks and hook configuration updates need to be ready in advance of 
> such a change.
 
Correct.

I am going to look into this in the next 6 months.

The work needs to be done with someone who has access to sourceware to
make and review such changes in the scripts and merge the changes upstream
with the official AdaCore hooks.

-- 
Cheers,
Carlos.

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On 14 Jan 2021 15:56, Carlos O'Donell wrote:
> On 1/14/21 12:54 PM, Joseph Myers wrote:
> > On Thu, 14 Jan 2021, Mike Frysinger via Libc-alpha wrote:
> >> On 30 Jun 2020 14:10, Carlos O'Donell via Libc-alpha wrote:
> >>> As we approach the release boundary for 2.32 we come to a natural point
> >>> where we can rename our development and release branch.
> >>>
> >>> My proposal would be to rename the development and current release branch:
> >>>
> >>> * master -> main
> >>
> >> this seems to have stalled.  we should do this!
> > 
> > Please see my previous comments.  Anyone making such a change needs to 
> > review the git hooks, hook configuration (e.g. 
> > refs/meta/config:project.config), hooks-bin scripts such as 
> > email-to-bugzilla-filtered and post-receive, and wiki and other 
> > documentation to identify *all* changes needed where master or branches 
> > containing the string "master" are special-cased or otherwise mentioned.  
> > The hooks and hook configuration updates need to be ready in advance of 
> > such a change.
>  
> Correct.
> 
> I am going to look into this in the next 6 months.
> 
> The work needs to be done with someone who has access to sourceware to
> make and review such changes in the scripts and merge the changes upstream
> with the official AdaCore hooks.

it wasn't clear to me if we thought we had consensus on the issue which
is why i wanted to kick the nest again.  it sounds like we do, so now
we can start on the messy process of actually changing things.

it does sound like all of the things to do before we can roll it out
are in the hooks.  if we can deploy a redirect, the docs don't have to
be done right away, and it'll give us more flexibility with a "soft"
release.

based on the tasks at hand, sounds like a wiki page would be best for
keeping track of everything to do ?  i don't think bugzilla is good
for checklists & adding/removing items, and creating multiple bugs
feels more like overhead than useful time.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Carlos O'Donell]

On 1/14/21 4:42 PM, Mike Frysinger wrote:
> On 14 Jan 2021 15:56, Carlos O'Donell wrote:
>> On 1/14/21 12:54 PM, Joseph Myers wrote:
>>> On Thu, 14 Jan 2021, Mike Frysinger via Libc-alpha wrote:
>>>> On 30 Jun 2020 14:10, Carlos O'Donell via Libc-alpha wrote:
>>>>> As we approach the release boundary for 2.32 we come to a natural point
>>>>> where we can rename our development and release branch.
>>>>>
>>>>> My proposal would be to rename the development and current release branch:
>>>>>
>>>>> * master -> main
>>>>
>>>> this seems to have stalled.  we should do this!
>>>
>>> Please see my previous comments.  Anyone making such a change needs to 
>>> review the git hooks, hook configuration (e.g. 
>>> refs/meta/config:project.config), hooks-bin scripts such as 
>>> email-to-bugzilla-filtered and post-receive, and wiki and other 
>>> documentation to identify *all* changes needed where master or branches 
>>> containing the string "master" are special-cased or otherwise mentioned.  
>>> The hooks and hook configuration updates need to be ready in advance of 
>>> such a change.
>>  
>> Correct.
>>
>> I am going to look into this in the next 6 months.
>>
>> The work needs to be done with someone who has access to sourceware to
>> make and review such changes in the scripts and merge the changes upstream
>> with the official AdaCore hooks.
> 
> it wasn't clear to me if we thought we had consensus on the issue which
> is why i wanted to kick the nest again.  it sounds like we do, so now
> we can start on the messy process of actually changing things.
> 
> it does sound like all of the things to do before we can roll it out
> are in the hooks.  if we can deploy a redirect, the docs don't have to
> be done right away, and it'll give us more flexibility with a "soft"
> release.
> 
> based on the tasks at hand, sounds like a wiki page would be best for
> keeping track of everything to do ?  i don't think bugzilla is good
> for checklists & adding/removing items, and creating multiple bugs
> feels more like overhead than useful time.

I agree. A wiki page checklist of things to check/review would be good.

Mostly I think it's just a lot of work and nobody has objected to someone
doing the work. It just has to be done well and with a high quality
solution, rather than something that is an abrupt change that requires
a lot of downstream fixing. Having said that, I don't know how to do
a redirect to keep old branches working (though I've seen it done in
Fedora when we wholesale moved from /foo to /rpms/foo).

-- 
Cheers,
Carlos.

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

[Mike Frysinger]

On 20 Jan 2021 08:49, Carlos O'Donell via Libc-alpha wrote:
> Having said that, I don't know how to do
> a redirect to keep old branches working (though I've seen it done in
> Fedora when we wholesale moved from /foo to /rpms/foo).

what branches are you thinking of ?  the old release branches ?  tbh, i
think we should just look forward.  lets focus on refs/heads/master ->
refs/heads/main.  changing that branch requires updating hooks and such,
but no other branches should break.

then for release branches, new ones will use main instead of master from
the very start.  nothing will break as they're all new refs.  people might
have to update their scripts to work with the new releases, but they have
to do that anyways to pull the upgrade.  existing stuff won't break.

so much like we aren't going to go through the git history and rewrite
all references to "master", leave the old branches alone as well.  if
anything, it stands out as "there was a mistake and we rectified it".
as we generate new branches, they'll slowly age out of the default list
of active branches.

if you really really want to rename those old branches, it can be done
after we clean up ToT and stop generating new bad branches ... let's
not hold back all progress because the long legacy tail is hard :).
-mike

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

[Carlos O'Donell]

On 1/20/21 7:23 PM, Mike Frysinger wrote:
> On 20 Jan 2021 08:49, Carlos O'Donell via Libc-alpha wrote:
>> Having said that, I don't know how to do
>> a redirect to keep old branches working (though I've seen it done in
>> Fedora when we wholesale moved from /foo to /rpms/foo).
> 
> what branches are you thinking of ?  the old release branches ?  tbh, i
> think we should just look forward.  lets focus on refs/heads/master ->
> refs/heads/main.  changing that branch requires updating hooks and such,
> but no other branches should break.

I am only thinking of master->main. Consensus was not to change any release
branches.

I would like the master->main transition be possible to do with a redirection
so we don't break existing checkouts and scripts.

I think that transition can be done with redirection because I saw something
like this done in Fedora, but I haven't reviewed the solution.

The problem of redirecting one branch, or all branches is effectively the
same problem just solved once (and then solved later again if we want).
 
> then for release branches, new ones will use main instead of master from
> the very start.  nothing will break as they're all new refs.  people might
> have to update their scripts to work with the new releases, but they have
> to do that anyways to pull the upgrade.  existing stuff won't break.

My intent would be that with redirection nothing breaks.
 
> so much like we aren't going to go through the git history and rewrite
> all references to "master", leave the old branches alone as well.  if
> anything, it stands out as "there was a mistake and we rectified it".
> as we generate new branches, they'll slowly age out of the default list
> of active branches.

Agreed.
 
> if you really really want to rename those old branches, it can be done
> after we clean up ToT and stop generating new bad branches ... let's
> not hold back all progress because the long legacy tail is hard :).

Agreed.

-- 
Cheers,
Carlos.

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

[Andreas Schwab]

On Jan 21 2021, Carlos O'Donell via Libc-alpha wrote:

> I think that transition can be done with redirection because I saw something
> like this done in Fedora, but I haven't reviewed the solution.

The redirection needs to be performed by git, by creating a symbolic ref
on the server.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Mike Frysinger]

On 21 Jan 2021 08:30, Carlos O'Donell via Libc-alpha wrote:
> On 1/20/21 7:23 PM, Mike Frysinger wrote:
> > On 20 Jan 2021 08:49, Carlos O'Donell via Libc-alpha wrote:
> >> Having said that, I don't know how to do
> >> a redirect to keep old branches working (though I've seen it done in
> >> Fedora when we wholesale moved from /foo to /rpms/foo).
> > 
> > what branches are you thinking of ?  the old release branches ?  tbh, i
> > think we should just look forward.  lets focus on refs/heads/master ->
> > refs/heads/main.  changing that branch requires updating hooks and such,
> > but no other branches should break.
> 
> I am only thinking of master->main. Consensus was not to change any release
> branches.
> 
> I would like the master->main transition be possible to do with a redirection
> so we don't break existing checkouts and scripts.
> 
> I think that transition can be done with redirection because I saw something
> like this done in Fedora, but I haven't reviewed the solution.

i noted earlier that i was able to set up a redirect on my server:
	$ cat refs/heads/master
	ref: refs/heads/main

setting up a redirect to ease people/scripts over to "main" sounds great,
but imo, we shouldn't leave it there forever.  scripts will need to change.
if the point is to bury master, leaving it as a perm symlink defeats that.

> The problem of redirecting one branch, or all branches is effectively the
> same problem just solved once (and then solved later again if we want).

right, i just wanted to make sure we weren't going to stall waiting for a
complete solution for everything when we have a path for refs/heads/master.

for the wiki page, doesn't seem like we've been great at organizing into
namespaces.  we do have "GlibcGit" though, so maybe the page would be:
	https://sourceware.org/glibc/wiki/GlibcGit/MigrationToMain

if that sounds fine, i can populate it with the content we've already
produced in these threads.  obviously the real work is left to an admin
(i.e. you) as the rest of can only backseat drive ;).
-mike

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

[Carlos O'Donell]

On 1/21/21 12:06 PM, Mike Frysinger wrote:
> On 21 Jan 2021 08:30, Carlos O'Donell via Libc-alpha wrote:
>> On 1/20/21 7:23 PM, Mike Frysinger wrote:
>>> On 20 Jan 2021 08:49, Carlos O'Donell via Libc-alpha wrote:
>>>> Having said that, I don't know how to do
>>>> a redirect to keep old branches working (though I've seen it done in
>>>> Fedora when we wholesale moved from /foo to /rpms/foo).
>>>
>>> what branches are you thinking of ?  the old release branches ?  tbh, i
>>> think we should just look forward.  lets focus on refs/heads/master ->
>>> refs/heads/main.  changing that branch requires updating hooks and such,
>>> but no other branches should break.
>>
>> I am only thinking of master->main. Consensus was not to change any release
>> branches.
>>
>> I would like the master->main transition be possible to do with a redirection
>> so we don't break existing checkouts and scripts.
>>
>> I think that transition can be done with redirection because I saw something
>> like this done in Fedora, but I haven't reviewed the solution.
> 
> i noted earlier that i was able to set up a redirect on my server:
> 	$ cat refs/heads/master
> 	ref: refs/heads/main
> 
> setting up a redirect to ease people/scripts over to "main" sounds great,
> but imo, we shouldn't leave it there forever.  scripts will need to change.
> if the point is to bury master, leaving it as a perm symlink defeats that.

I think Fedora left the link there for a year. That's fine with me. We also
announce it far and wide that it's changing. When the link was in place in
Fedora git kept issuing an annoying message reminding you it was doing
a redirect and that was useful to remind you to update your repo.
 
>> The problem of redirecting one branch, or all branches is effectively the
>> same problem just solved once (and then solved later again if we want).
> 
> right, i just wanted to make sure we weren't going to stall waiting for a
> complete solution for everything when we have a path for refs/heads/master.
> 
> for the wiki page, doesn't seem like we've been great at organizing into
> namespaces.  we do have "GlibcGit" though, so maybe the page would be:
> 	https://sourceware.org/glibc/wiki/GlibcGit/MigrationToMain

Sure.
 
> if that sounds fine, i can populate it with the content we've already
> produced in these threads.  obviously the real work is left to an admin
> (i.e. you) as the rest of can only backseat drive ;).

Having a checklist is *immensely* helpful.

-- 
Cheers,
Carlos.

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

[Andreas Schwab]

On Jan 21 2021, Carlos O'Donell via Libc-alpha wrote:

> I think Fedora left the link there for a year.

Are you sure you are talking about the same kind of link?  There is a
fundamental difference between repository URL rewriting (which is
implemented by the web server) and renaming a branch in a git
repository.

> When the link was in place in Fedora git kept issuing an annoying
> message reminding you it was doing a redirect and that was useful to
> remind you to update your repo.

That only happens for a repo URL redirect, and only for http(s) URLs.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Mike Frysinger]

initial cut up:
https://sourceware.org/glibc/wiki/GlibcGit/MigrationToMain

feel free to add/remove/edit anything that comes to mind.
hopefully i was able to capture everything from this thread.
-mike