Rename "master" branch to "main" for glibc 2.35 release.

Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

In June 2020 I started this thread for glibc 2.32:
https://sourceware.org/pipermail/libc-alpha/2020-June/115579.html
to discuss a branch name change.

Thanks to Paul, Florian, Joseph and DJ who provided feedback on
the initial discussion.

As of today the default Gitlab new branch is "main" (Gitlab 14 or later).

As of today the default Github new branch is "main".

With Git 2.28+ the default branch name is configurable.

Git has added this advisory text:
~~~
 562 static const char default_branch_name_advice[] = N_(
 563 "Using '%s' as the name for the initial branch. This default branch name\n"
 564 "is subject to change. To configure the initial branch name to use in all\n"
 565 "of your new repositories, which will suppress this warning, call:\n"
 566 "\n"
 567 "\tgit config --global init.defaultBranch <name>\n"
 568 "\n"
 569 "Names commonly chosen instead of 'master' are 'main', 'trunk' and\n"
 570 "'development'. The just-created branch can be renamed via this command:\n"
 571 "\n"
 572 "\tgit branch -m <name>\n"
~~~

My proposal is to rename the development and release branches at the point
that glibc 2.35 branches:

* master -> main

* release/2.35/master -> release/2.35/main

No alias would be provided for the master branch; we would immediately
start using 'main' as the development branch.

I am looking for consensus on this proposal.

Details:
========

Given the feedback from the last proposal I have done the required
review to ensure the transition can happen smoothly within our own
infrastructure.

This proposal is only about the development branch and upcoming release
branch. All historical branches remain at their existing names.

I have reviewed the git hooks, and we would need to make changes to the
following files after the transition:
* hooks-bin/email-to-bugzilla-filtered
* hooks-bin/post-receive

Our hooks implementation (AdaCore's hooks) is neutral on the branch name
used. There are two instances where 'master' is removed for '' to
shorten an email message because it's the "default", but that should not
be a blocker for our transition.

There are changes required to our project.config in refs/meta/config:
* reject-merge-commits for 'main' needs to be set.
* allow-non-fast-forward must be adjusted for 'main'.

Wiki pages that need changing immediately:
* https://sourceware.org/glibc/wiki/GlibcGit

How to update a renamed upstream branch:
# Rename old branch to new branch.
$ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
# Fetch upstream origin to get new branch name.
$ git fetch origin
# Set upstream to thew new renamed branch.
$ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
# Set the default branch for origin automatically
$ git remote set-head origin -a
# Prune the old references away.
$ git remote prune origin

Website needs updating immediately:
* https://www.gnu.org/software/libc/sources.html
* https://www.gnu.org/software/libc/started.html

All other wiki, web, and source references can be adjusted over time.

-- 
Cheers,
Carlos.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Phil Blundell]

On Sat, Jan 29, 2022 at 05:32:33PM -0500, Carlos O'Donell via Libc-alpha wrote:
> My proposal is to rename the development and release branches at the point
> that glibc 2.35 branches:
> 
> * master -> main
> 
> * release/2.35/master -> release/2.35/main
> 
> No alias would be provided for the master branch; we would immediately
> start using 'main' as the development branch.
> 
> I am looking for consensus on this proposal.

I support this proposal.

Thanks

Phil

Re: Rename "master" branch to "main" for glibc 2.35 release.

[DJ Delorie]

"Carlos O'Donell" <carlos@redhat.com> writes:
> No alias would be provided for the master branch;

This would invalidate decades of online documentation in an instant, and
for that alone I oppose this part of your proposal.

It will also break existing git checkouts, even if you write very clear
documenation (you did, right? ;) about how to "fix" a checked out master
branch.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Mike Frysinger]

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

On 29 Jan 2022 18:33, DJ Delorie via Libc-alpha wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
> > No alias would be provided for the master branch;
> 
> This would invalidate decades of online documentation in an instant, and
> for that alone I oppose this part of your proposal.

might want to tamper the hyperbole.  glibc hasn't been using git for decades.
i don't recall the exact date, but it seems it's been just about one decade.

what documentation exactly are you concerned about here ?  people linking to
the online git viewer ?  people linking to commits/diffs don't have "master"
in the URI, just the commit id.

> It will also break existing git checkouts, even if you write very clear
> documenation (you did, right? ;) about how to "fix" a checked out master
> branch.

this is making much ado about nothing.  "fixing" a checkout is a single
command to change what branch is being used to merge.  even then, it's not
like the world will explode if someone has to manually fixup their checkout
once.

we can keep the master branch and just delete all content.  replace it with
a file that says "use main".  or something like that.

there's no need to keep "master" redirecting to "main" forever, or really
at all.  plenty of other projects of significantly larger magnitude than
glibc have migrated without doing this.
-mike

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

Re: Rename "master" branch to "main" for glibc 2.35 release.

[DJ Delorie]

Mike Frysinger <vapier@gentoo.org> writes:
> what documentation exactly are you concerned about here ?

I don't know, which is a bit frightening.  How many web pages on the
internet talk about glibc's "master" branch?  I pretty regularly run
across web pages that are worse than useless because they rely on "the
old way" and I'd like to avoid that if possible, and leaving behind an
alias is both possible and pretty trivial.

> this is making much ado about nothing.  "fixing" a checkout is a single
> command to change what branch is being used to merge.  even then, it's not
> like the world will explode if someone has to manually fixup their checkout
> once.

Did you write up those instructions?  *I* don't know how to do it, other
than "delete tree; checkout fresh".  Do you know where users will go
searching for those instructions?  Unless you put a highly obvious note
on the top of glibc's wiki home page, I bet most people won't be able to
easily find it.

The internet is a mess and the best instructions are "you don't need to
do anything, it will just work" because of that.

> there's no need to keep "master" redirecting to "main" forever,

There's no reason to not keep it either.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Mike Frysinger]

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

On 29 Jan 2022 21:10, DJ Delorie wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > what documentation exactly are you concerned about here ?
> 
> I don't know, which is a bit frightening.  How many web pages on the
> internet talk about glibc's "master" branch?  I pretty regularly run
> across web pages that are worse than useless because they rely on "the
> old way" and I'd like to avoid that if possible, and leaving behind an
> alias is both possible and pretty trivial.

the docs will change, or they're obsolete.  the world didn't fall down when
we moved from cvs to git.  or any other toolchain project that moved from
cvs to git, or to svn and then git.  this is a lot of drama for nothing.

> > this is making much ado about nothing.  "fixing" a checkout is a single
> > command to change what branch is being used to merge.  even then, it's not
> > like the world will explode if someone has to manually fixup their checkout
> > once.
> 
> Did you write up those instructions?  *I* don't know how to do it, other
> than "delete tree; checkout fresh".  Do you know where users will go
> searching for those instructions?  Unless you put a highly obvious note
> on the top of glibc's wiki home page, I bet most people won't be able to
> easily find it.
> 
> The internet is a mess and the best instructions are "you don't need to
> do anything, it will just work" because of that.

the docs already exist.
https://sourceware.org/glibc/wiki/GlibcGit/MigrationToMain
-mike

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

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Paul Eggert]

On 1/29/22 14:32, Carlos O'Donell wrote:
> All other wiki, web, and source references can be adjusted over time.

By "source references" I assume you mean the occurrences of "master" in 
scripts/backport-support.sh and scripts/build-many-glibcs.py. I assume 
these would be updated in very short order. (Or did I miss some 
occurrences?)

I'm in favor of the change, just as I was the last time you asked. Of 
course it will entail work but the amount of effort should be small.


For what it's worth I renamed tzdb's "master" to "main" in March 2021. 
Although tzdb is much smaller than glibc, it has dozens of downstream 
projects and there were some nontechnical complaints (one commenter 
called the change "profoundly silly"). I recall only one technical 
problem being reported, though, and it was minor 
<https://mm.icann.org/pipermail/tz/2021-March/029944.html>. To help 
prevent that problem from occurring with glibc it might be helpful to 
suggest that each developer with a local clone adjust to the change 
after it's installed, by issuing something like the following shell 
commands.

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a
git remote prune origin

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Siddhesh Poyarekar]

On 30/01/2022 08:05, Paul Eggert wrote:
> git branch -m master main
> git fetch origin
> git branch -u origin/main main
> git remote set-head origin -a
> git remote prune origin
> 

... and maybe even reject pushes to the master branch with a message 
instructing developers to do the above?

Thanks,
Siddhesh

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Florian Weimer]

* Carlos O'Donell:

> My proposal is to rename the development and release branches at the point
> that glibc 2.35 branches:
>
> * master -> main
>
> * release/2.35/master -> release/2.35/main
>
> No alias would be provided for the master branch; we would immediately
> start using 'main' as the development branch.

What is the reason for using ”main” for release branches?

If we don't add a symbolic ref, we could use release/2.35.

Thanks,
Florian

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Andreas Schwab]

On Jan 31 2022, Florian Weimer via Libc-alpha wrote:

> * Carlos O'Donell:
>
>> My proposal is to rename the development and release branches at the point
>> that glibc 2.35 branches:
>>
>> * master -> main
>>
>> * release/2.35/master -> release/2.35/main
>>
>> No alias would be provided for the master branch; we would immediately
>> start using 'main' as the development branch.
>
> What is the reason for using ”main” for release branches?
>
> If we don't add a symbolic ref, we could use release/2.35.

Note that release/2.35 and release/2.35/main cannot coexist with the
current ref store format.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

On 1/31/22 07:46, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> My proposal is to rename the development and release branches at the point
>> that glibc 2.35 branches:
>>
>> * master -> main
>>
>> * release/2.35/master -> release/2.35/main
>>
>> No alias would be provided for the master branch; we would immediately
>> start using 'main' as the development branch.
> 
> What is the reason for using ”main” for release branches?

There is no strong justification for using 'main' for release branches.

It is a continuation of the existing format of branch names, and so would
require only a search and replace in your script.
 
> If we don't add a symbolic ref, we could use release/2.35.

Andreas points out that release/2.35 and release/2.35/main cannot coexist
so that would mean we would need to make a choice about which to use and
stick with that choice:

* master -> main
* release/2.35/master -> release/2.35

We could not then go back and have:

* release/2.35/main
* release/2.35/foo
* release/2.35/bar

If we ever wanted alternative non-main branches for glibc 2.35?

This consideration means I'm in favor of keeping the existing structure
of release/2.35/main.

-- 
Cheers,
Carlos.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Dmitry V. Levin]

On Mon, Jan 31, 2022 at 09:55:26AM -0500, Carlos O'Donell via Libc-alpha wrote:
> On 1/31/22 07:46, Florian Weimer wrote:
> > * Carlos O'Donell:
> > 
> >> My proposal is to rename the development and release branches at the point
> >> that glibc 2.35 branches:
> >>
> >> * master -> main
> >>
> >> * release/2.35/master -> release/2.35/main
> >>
> >> No alias would be provided for the master branch; we would immediately
> >> start using 'main' as the development branch.
> > 
> > What is the reason for using ”main” for release branches?
> 
> There is no strong justification for using 'main' for release branches.
> 
> It is a continuation of the existing format of branch names, and so would
> require only a search and replace in your script.
>  
> > If we don't add a symbolic ref, we could use release/2.35.
> 
> Andreas points out that release/2.35 and release/2.35/main cannot coexist
> so that would mean we would need to make a choice about which to use and
> stick with that choice:
> 
> * master -> main
> * release/2.35/master -> release/2.35
> 
> We could not then go back and have:
> 
> * release/2.35/main
> * release/2.35/foo
> * release/2.35/bar
> 
> If we ever wanted alternative non-main branches for glibc 2.35?

There haven't been any branches with "release/" prefix besides
"release/2.??/master" yet, so what's the reason to expect them appear
in case of glibc 2.35?

Are you talking about a theoretical possibility of creating an
alternative branch name with "release/2.35/" prefix some day in the
future, or is it something more practical?


-- 
ldv

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

On 1/31/22 19:59, Dmitry V. Levin wrote:
> On Mon, Jan 31, 2022 at 09:55:26AM -0500, Carlos O'Donell via Libc-alpha wrote:
>> On 1/31/22 07:46, Florian Weimer wrote:
>>> * Carlos O'Donell:
>>>
>>>> My proposal is to rename the development and release branches at the point
>>>> that glibc 2.35 branches:
>>>>
>>>> * master -> main
>>>>
>>>> * release/2.35/master -> release/2.35/main
>>>>
>>>> No alias would be provided for the master branch; we would immediately
>>>> start using 'main' as the development branch.
>>>
>>> What is the reason for using ”main” for release branches?
>>
>> There is no strong justification for using 'main' for release branches.
>>
>> It is a continuation of the existing format of branch names, and so would
>> require only a search and replace in your script.
>>  
>>> If we don't add a symbolic ref, we could use release/2.35.
>>
>> Andreas points out that release/2.35 and release/2.35/main cannot coexist
>> so that would mean we would need to make a choice about which to use and
>> stick with that choice:
>>
>> * master -> main
>> * release/2.35/master -> release/2.35
>>
>> We could not then go back and have:
>>
>> * release/2.35/main
>> * release/2.35/foo
>> * release/2.35/bar
>>
>> If we ever wanted alternative non-main branches for glibc 2.35?
> 
> There haven't been any branches with "release/" prefix besides
> "release/2.??/master" yet, so what's the reason to expect them appear
> in case of glibc 2.35?
> 
> Are you talking about a theoretical possibility of creating an
> alternative branch name with "release/2.35/" prefix some day in the
> future, or is it something more practical?

No, just the theoretical possibility.

I have no objection to just a bare release/2.35 as the branch name.

I guess that's certainly a step we could take e.g. name the release
branch release/2.35 (omitting "master").

-- 
Cheers,
Carlos.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Tulio Magno Quites Machado Filho]

Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org> writes:

> In June 2020 I started this thread for glibc 2.32:
> https://sourceware.org/pipermail/libc-alpha/2020-June/115579.html
> to discuss a branch name change.
>
> Thanks to Paul, Florian, Joseph and DJ who provided feedback on
> the initial discussion.
>
> As of today the default Gitlab new branch is "main" (Gitlab 14 or later).
>
> As of today the default Github new branch is "main".
>
> With Git 2.28+ the default branch name is configurable.
>
> Git has added this advisory text:
> ~~~
>  562 static const char default_branch_name_advice[] = N_(
>  563 "Using '%s' as the name for the initial branch. This default branch name\n"
>  564 "is subject to change. To configure the initial branch name to use in all\n"
>  565 "of your new repositories, which will suppress this warning, call:\n"
>  566 "\n"
>  567 "\tgit config --global init.defaultBranch <name>\n"
>  568 "\n"
>  569 "Names commonly chosen instead of 'master' are 'main', 'trunk' and\n"
>  570 "'development'. The just-created branch can be renamed via this command:\n"
>  571 "\n"
>  572 "\tgit branch -m <name>\n"
> ~~~
>
> My proposal is to rename the development and release branches at the point
> that glibc 2.35 branches:
>
> * master -> main
>
> * release/2.35/master -> release/2.35/main
>
> No alias would be provided for the master branch; we would immediately
> start using 'main' as the development branch.
>
> I am looking for consensus on this proposal.

I also agree with this proposal.

One of the documentation that will be impacted by this change is:
https://www.sourceware.org/glibc/wiki/Development_Todo/Master

I don't think that's meaningful impact for halting this migration, though.

CI systems might need to be modified too, e.g.
https://sourceware.org/git/?p=glibc-buildbot.git;a=blob;f=master.cfg;h=08321a67bbdea7f48989e691e48feeb3c3ead66b;hb=HEAD#l63
Again, I don't think this is a problem.

I'd also like to take the chance and remove branch ibm/master.  It hasn't been
used in years and I don't think it has any historic value.

-- 
Tulio Magno

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Joseph Myers]

On Sat, 29 Jan 2022, Carlos O'Donell via Libc-alpha wrote:

> My proposal is to rename the development and release branches at the point
> that glibc 2.35 branches:
> 
> * master -> main
> 
> * release/2.35/master -> release/2.35/main
> 
> No alias would be provided for the master branch; we would immediately
> start using 'main' as the development branch.

I strongly disapprove of the approach of renaming an existing branch 
without providing an alias.  Branches aren't just consumed by active 
developers, there are many people with their own checkouts, automatically 
updating mirrors, etc., many of which may be useful to their users without 
much active maintenance and without anyone following glibc mailing lists; 
it's gratuitous to break them.

Note also that build-many-glibcs.py knows about migrating GCC checkouts 
from SVN to git, so no manual intervention whatever was needed beyond the 
use of --replace-sources when running the checkout step (which is used 
automatically in bot mode).  Naturally it should be taught to migrate from 
master to main if the master alias might ever go away (but I don't think 
such an alias should go away, certainly not for several years).

(This is not making any assertion about whether it should be possible to 
push to the master alias, just that nothing should be broken for anyone 
pulling from it.)

> I have reviewed the git hooks, and we would need to make changes to the
> following files after the transition:
> * hooks-bin/email-to-bugzilla-filtered
> * hooks-bin/post-receive
> 
> Our hooks implementation (AdaCore's hooks) is neutral on the branch name
> used. There are two instances where 'master' is removed for '' to
> shorten an email message because it's the "default", but that should not
> be a blocker for our transition.

Configuration to handle the two branch names the same in all regards 
should be done before adding a branch using the new naming conventions.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Dan Raymond]

"this is making much ado about nothing"


"it's not like the world will explode"
"this is a lot of drama for nothing"

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Dan Raymond]

In my opinion it is not appropriate to trivialize objections over this 
proposal.  The burden lies on the side of those who support the proposal 
to provide justification for it.  If the change will cause pain for a 
lot of users and it is purely an aesthetic change then I vote we should 
reject the proposal.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

On 1/31/22 11:19, Joseph Myers wrote:
> On Sat, 29 Jan 2022, Carlos O'Donell via Libc-alpha wrote:
> 
>> My proposal is to rename the development and release branches at the point
>> that glibc 2.35 branches:
>>
>> * master -> main
>>
>> * release/2.35/master -> release/2.35/main
>>
>> No alias would be provided for the master branch; we would immediately
>> start using 'main' as the development branch.
> 
> I strongly disapprove of the approach of renaming an existing branch 
> without providing an alias.  Branches aren't just consumed by active 
> developers, there are many people with their own checkouts, automatically 
> updating mirrors, etc., many of which may be useful to their users without 
> much active maintenance and without anyone following glibc mailing lists; 
> it's gratuitous to break them.

Just for clarity then, if we do the work to support "main" and "master", and add an alias
from "master" to "main" (git status would show as being on "main"), would that have
your support?

-- 
Cheers,
Carlos.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Joseph Myers]

On Mon, 31 Jan 2022, Carlos O'Donell via Libc-alpha wrote:

> Just for clarity then, if we do the work to support "main" and "master", 
> and add an alias from "master" to "main" (git status would show as being 
> on "main"), would that have your support?

I'm fine with making the change if (a) we have an alias (created with "git 
symbolic-ref", I suppose) to avoid breaking existing checkouts, at least 
for reading and (b) the hook / hook configuration changes to handle "main" 
the same as master are done before the "main" name is set up.

If the alias might end up getting removed, add (c) build-many-glibcs.py is 
set up to transition its checkouts to the new name automatically, at least 
a year in advance of the removal.

An alias is not of course needed for release/2.35/main if no branch 
release/2.35/master was ever created, but some of the hook changes *are* 
needed to apply appropriate commit rules to release/2.35/main.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

On 1/31/22 18:04, Joseph Myers wrote:
> On Mon, 31 Jan 2022, Carlos O'Donell via Libc-alpha wrote:
> 
>> Just for clarity then, if we do the work to support "main" and "master", 
>> and add an alias from "master" to "main" (git status would show as being 
>> on "main"), would that have your support?
> 
> I'm fine with making the change if (a) we have an alias (created with "git 
> symbolic-ref", I suppose) to avoid breaking existing checkouts, at least 
> for reading and (b) the hook / hook configuration changes to handle "main" 
> the same as master are done before the "main" name is set up.

I agree to that.

> If the alias might end up getting removed, add (c) build-many-glibcs.py is 
> set up to transition its checkouts to the new name automatically, at least 
> a year in advance of the removal.

Agreed.

> An alias is not of course needed for release/2.35/main if no branch 
> release/2.35/master was ever created, but some of the hook changes *are* 
> needed to apply appropriate commit rules to release/2.35/main.

Correct.

-- 
Cheers,
Carlos.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Adhemerval Zanella]

On 29/01/2022 19:32, Carlos O'Donell via Libc-alpha wrote:
> In June 2020 I started this thread for glibc 2.32:
> https://sourceware.org/pipermail/libc-alpha/2020-June/115579.html
> to discuss a branch name change.
> 
> Thanks to Paul, Florian, Joseph and DJ who provided feedback on
> the initial discussion.
> 
> As of today the default Gitlab new branch is "main" (Gitlab 14 or later).
> 
> As of today the default Github new branch is "main".
> 
> With Git 2.28+ the default branch name is configurable.
> 
> Git has added this advisory text:
> ~~~
>  562 static const char default_branch_name_advice[] = N_(
>  563 "Using '%s' as the name for the initial branch. This default branch name\n"
>  564 "is subject to change. To configure the initial branch name to use in all\n"
>  565 "of your new repositories, which will suppress this warning, call:\n"
>  566 "\n"
>  567 "\tgit config --global init.defaultBranch <name>\n"
>  568 "\n"
>  569 "Names commonly chosen instead of 'master' are 'main', 'trunk' and\n"
>  570 "'development'. The just-created branch can be renamed via this command:\n"
>  571 "\n"
>  572 "\tgit branch -m <name>\n"
> ~~~
> 
> My proposal is to rename the development and release branches at the point
> that glibc 2.35 branches:
> 
> * master -> main
> 
> * release/2.35/master -> release/2.35/main
> 
> No alias would be provided for the master branch; we would immediately
> start using 'main' as the development branch.
> 
> I am looking for consensus on this proposal.
> 
> Details:
> ========
> 
> Given the feedback from the last proposal I have done the required
> review to ensure the transition can happen smoothly within our own
> infrastructure.
> 
> This proposal is only about the development branch and upcoming release
> branch. All historical branches remain at their existing names.
> 
> I have reviewed the git hooks, and we would need to make changes to the
> following files after the transition:
> * hooks-bin/email-to-bugzilla-filtered
> * hooks-bin/post-receive
> 
> Our hooks implementation (AdaCore's hooks) is neutral on the branch name
> used. There are two instances where 'master' is removed for '' to
> shorten an email message because it's the "default", but that should not
> be a blocker for our transition.
> 
> There are changes required to our project.config in refs/meta/config:
> * reject-merge-commits for 'main' needs to be set.
> * allow-non-fast-forward must be adjusted for 'main'.
> 
> Wiki pages that need changing immediately:
> * https://sourceware.org/glibc/wiki/GlibcGit
> 
> How to update a renamed upstream branch:
> # Rename old branch to new branch.
> $ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
> # Fetch upstream origin to get new branch name.
> $ git fetch origin
> # Set upstream to thew new renamed branch.
> $ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
> # Set the default branch for origin automatically
> $ git remote set-head origin -a
> # Prune the old references away.
> $ git remote prune origin
> 
> Website needs updating immediately:
> * https://www.gnu.org/software/libc/sources.html
> * https://www.gnu.org/software/libc/started.html
> 
> All other wiki, web, and source references can be adjusted over time.
> 

I must say that I am failing to see any technical advantage or improvement
of doing this change.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[H.J. Lu]

On Mon, Jan 31, 2022 at 10:09 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 29/01/2022 19:32, Carlos O'Donell via Libc-alpha wrote:
> > In June 2020 I started this thread for glibc 2.32:
> > https://sourceware.org/pipermail/libc-alpha/2020-June/115579.html
> > to discuss a branch name change.
> >
> > Thanks to Paul, Florian, Joseph and DJ who provided feedback on
> > the initial discussion.
> >
> > As of today the default Gitlab new branch is "main" (Gitlab 14 or later).
> >
> > As of today the default Github new branch is "main".
> >
> > With Git 2.28+ the default branch name is configurable.
> >
> > Git has added this advisory text:
> > ~~~
> >  562 static const char default_branch_name_advice[] = N_(
> >  563 "Using '%s' as the name for the initial branch. This default branch name\n"
> >  564 "is subject to change. To configure the initial branch name to use in all\n"
> >  565 "of your new repositories, which will suppress this warning, call:\n"
> >  566 "\n"
> >  567 "\tgit config --global init.defaultBranch <name>\n"
> >  568 "\n"
> >  569 "Names commonly chosen instead of 'master' are 'main', 'trunk' and\n"
> >  570 "'development'. The just-created branch can be renamed via this command:\n"
> >  571 "\n"
> >  572 "\tgit branch -m <name>\n"
> > ~~~
> >
> > My proposal is to rename the development and release branches at the point
> > that glibc 2.35 branches:
> >
> > * master -> main
> >
> > * release/2.35/master -> release/2.35/main
> >
> > No alias would be provided for the master branch; we would immediately
> > start using 'main' as the development branch.
> >
> > I am looking for consensus on this proposal.
> >
> > Details:
> > ========
> >
> > Given the feedback from the last proposal I have done the required
> > review to ensure the transition can happen smoothly within our own
> > infrastructure.
> >
> > This proposal is only about the development branch and upcoming release
> > branch. All historical branches remain at their existing names.
> >
> > I have reviewed the git hooks, and we would need to make changes to the
> > following files after the transition:
> > * hooks-bin/email-to-bugzilla-filtered
> > * hooks-bin/post-receive
> >
> > Our hooks implementation (AdaCore's hooks) is neutral on the branch name
> > used. There are two instances where 'master' is removed for '' to
> > shorten an email message because it's the "default", but that should not
> > be a blocker for our transition.
> >
> > There are changes required to our project.config in refs/meta/config:
> > * reject-merge-commits for 'main' needs to be set.
> > * allow-non-fast-forward must be adjusted for 'main'.
> >
> > Wiki pages that need changing immediately:
> > * https://sourceware.org/glibc/wiki/GlibcGit
> >
> > How to update a renamed upstream branch:
> > # Rename old branch to new branch.
> > $ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
> > # Fetch upstream origin to get new branch name.
> > $ git fetch origin
> > # Set upstream to thew new renamed branch.
> > $ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
> > # Set the default branch for origin automatically
> > $ git remote set-head origin -a
> > # Prune the old references away.
> > $ git remote prune origin
> >
> > Website needs updating immediately:
> > * https://www.gnu.org/software/libc/sources.html
> > * https://www.gnu.org/software/libc/started.html
> >
> > All other wiki, web, and source references can be adjusted over time.
> >
>
> I must say that I am failing to see any technical advantage or improvement
> of doing this change.

Same here.  If we do want to change, I think "dev" is better than "main".
"dev" indicates that the branch is under development.

-- 
H.J.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Adhemerval Zanella]

On 31/01/2022 15:14, H.J. Lu wrote:
> On Mon, Jan 31, 2022 at 10:09 AM Adhemerval Zanella via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>>
>>
>> On 29/01/2022 19:32, Carlos O'Donell via Libc-alpha wrote:
>>> In June 2020 I started this thread for glibc 2.32:
>>> https://sourceware.org/pipermail/libc-alpha/2020-June/115579.html
>>> to discuss a branch name change.
>>>
>>> Thanks to Paul, Florian, Joseph and DJ who provided feedback on
>>> the initial discussion.
>>>
>>> As of today the default Gitlab new branch is "main" (Gitlab 14 or later).
>>>
>>> As of today the default Github new branch is "main".
>>>
>>> With Git 2.28+ the default branch name is configurable.
>>>
>>> Git has added this advisory text:
>>> ~~~
>>>  562 static const char default_branch_name_advice[] = N_(
>>>  563 "Using '%s' as the name for the initial branch. This default branch name\n"
>>>  564 "is subject to change. To configure the initial branch name to use in all\n"
>>>  565 "of your new repositories, which will suppress this warning, call:\n"
>>>  566 "\n"
>>>  567 "\tgit config --global init.defaultBranch <name>\n"
>>>  568 "\n"
>>>  569 "Names commonly chosen instead of 'master' are 'main', 'trunk' and\n"
>>>  570 "'development'. The just-created branch can be renamed via this command:\n"
>>>  571 "\n"
>>>  572 "\tgit branch -m <name>\n"
>>> ~~~
>>>
>>> My proposal is to rename the development and release branches at the point
>>> that glibc 2.35 branches:
>>>
>>> * master -> main
>>>
>>> * release/2.35/master -> release/2.35/main
>>>
>>> No alias would be provided for the master branch; we would immediately
>>> start using 'main' as the development branch.
>>>
>>> I am looking for consensus on this proposal.
>>>
>>> Details:
>>> ========
>>>
>>> Given the feedback from the last proposal I have done the required
>>> review to ensure the transition can happen smoothly within our own
>>> infrastructure.
>>>
>>> This proposal is only about the development branch and upcoming release
>>> branch. All historical branches remain at their existing names.
>>>
>>> I have reviewed the git hooks, and we would need to make changes to the
>>> following files after the transition:
>>> * hooks-bin/email-to-bugzilla-filtered
>>> * hooks-bin/post-receive
>>>
>>> Our hooks implementation (AdaCore's hooks) is neutral on the branch name
>>> used. There are two instances where 'master' is removed for '' to
>>> shorten an email message because it's the "default", but that should not
>>> be a blocker for our transition.
>>>
>>> There are changes required to our project.config in refs/meta/config:
>>> * reject-merge-commits for 'main' needs to be set.
>>> * allow-non-fast-forward must be adjusted for 'main'.
>>>
>>> Wiki pages that need changing immediately:
>>> * https://sourceware.org/glibc/wiki/GlibcGit
>>>
>>> How to update a renamed upstream branch:
>>> # Rename old branch to new branch.
>>> $ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
>>> # Fetch upstream origin to get new branch name.
>>> $ git fetch origin
>>> # Set upstream to thew new renamed branch.
>>> $ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
>>> # Set the default branch for origin automatically
>>> $ git remote set-head origin -a
>>> # Prune the old references away.
>>> $ git remote prune origin
>>>
>>> Website needs updating immediately:
>>> * https://www.gnu.org/software/libc/sources.html
>>> * https://www.gnu.org/software/libc/started.html
>>>
>>> All other wiki, web, and source references can be adjusted over time.
>>>
>>
>> I must say that I am failing to see any technical advantage or improvement
>> of doing this change.
> 
> Same here.  If we do want to change, I think "dev" is better than "main".
> "dev" indicates that the branch is under development.
> 

I would prefer that if want to change the repo name for something else, we
might evaluate the development process as well. A 'dev' branch make sense 
in my view as a staging branch where we might have slight more freedom or 
work in way that changes are merger to the main/master branch. 

Re: Rename "master" branch to "main" for glibc 2.35 release.

[DJ Delorie]

Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> I must say that I am failing to see any technical advantage or improvement
> of doing this change.

There isn't any.  This is a response to a vocal group in the USA that
feels that words can't change, and "master/slave" will always mean
historic slavery and nothing else, and since their way is the only way,
the rest of the world has to change intead.

Obviously, I'm opposed to such things ;-)

The only example of "doing it right" I've seen so far, is that Fedora
changed their master branch to "rawhide" which actually makes a lot of
sense, since that's where that branch is used.

Note: I'm not opposed to renaming the master branch *per se*.  After
all, it's just a word.  I'm opposed to doing it *for those reasons* and
in a way which inconveniences our users.  Do it right, do it better, or
don't do it at all.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Siddhesh Poyarekar]

On 31/01/2022 23:58, DJ Delorie via Libc-alpha wrote:
> There isn't any.  This is a response to a vocal group in the USA that
> feels that words can't change, and "master/slave" will always mean
> historic slavery and nothing else, and since their way is the only way,
> the rest of the world has to change intead.

Well the N word can have different meanings too and the world did change 
to try and eliminate that word from popular vocabulary.  The swastika 
synbol (and the word) is almost universally frowned upon due to its Nazi 
links despite the fact that its original meaning is entirely something 
else to about 1/6th of the world's population.

So the idea of trying to eliminate a word or idea from popular 
vocabulary is not exactly new, we humans do it all the time.

Siddhesh

Re: Rename "master" branch to "main" for glibc 2.35 release.

[DJ Delorie]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> So the idea of trying to eliminate a word or idea from popular 
> vocabulary is not exactly new, we humans do it all the time.

But there are plenty of examples of words changing for the better, too.
Who doesn't want to master their fears?  Who isn't a slave to ambition?
Even POSIX doesn't stay the same forever...

But this is neither here nor there; it's our decision in this case, and
we should make it based on our reasons, not just because someone else
told us to do it.  And we can do it the way we want to, in a way which
is best for our users and community, which is why my only real
opposition is to invalidating old documentation, when keeping it working
is a trivial thing.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Siddhesh Poyarekar]

On 01/02/2022 09:14, DJ Delorie wrote:
> Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>> So the idea of trying to eliminate a word or idea from popular
>> vocabulary is not exactly new, we humans do it all the time.
> 
> But there are plenty of examples of words changing for the better, too.
> Who doesn't want to master their fears?  Who isn't a slave to ambition?
> Even POSIX doesn't stay the same forever...

Words don't change, new meanings get added in, often making differences 
murkier.  Take 'fuck' for example; the word has so many meanings but it 
has an underlying flavour that implies a level and type of aggression 
that not many are comfortable with expressing openly.

> But this is neither here nor there; it's our decision in this case, and
> we should make it based on our reasons, not just because someone else
> told us to do it.  And we can do it the way we want to, in a way which
> is best for our users and community, which is why my only real
> opposition is to invalidating old documentation, when keeping it working
> is a trivial thing.

Agreed, I think that's a point (or at least similar) that Joseph raised 
too; there's no strong reason to break links right away, especially for 
a project that has kept libio untouched for fear of breaking programs 
built with gcc 2.95.

Siddhesh

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

On 2/1/22 00:05, Siddhesh Poyarekar wrote:
> Agreed, I think that's a point (or at least similar) that Joseph
> raised too; there's no strong reason to break links right away,
> especially for a project that has kept libio untouched for fear of
> breaking programs built with gcc 2.95.

Currently gcc has trunk ref'ing master so you can use both trunk and master.

We could easily, and I don't object to it, have master be a symbolic-ref
for main. This appears to be the only part of the transition for which DJ
and Joseph have strong opinions.

I'll adjust the proposal, and link to Mike's wiki document too.

-- 
Cheers,
Carlos.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Siddhesh Poyarekar]

On 31/01/2022 23:39, Adhemerval Zanella via Libc-alpha wrote:
> I must say that I am failing to see any technical advantage or improvement
> of doing this change.
> 

There's no technical advantage because it is not a technical issue to 
begin with.  In fact, rejecting the suggestion saying that there's no 
technical advantage sends the unsaid message that we don't care enough 
to give this social issue any more serious thought than trying to glean 
technical merit from it.

I personally have no lived experience about the master/slave 
nomenclature since I'm not from the USA and I'm not 
African/African-American.  I don't think we have any regular African or 
African-American contributors either who could share their experiences 
about how (or if) the nomenclature affects them.  We're a mostly white 
community with smidges of Asian for flavour, albeit geographically very 
diverse (perhaps our relative ignorance/indifference towards this 
mostly-American origin movement is because of the latter) so I don't 
think any of us can reasonably speak to this.

My personal impression is that mentorship/paid programs would do far 
more good than renaming things, but it's just that, a third person 
impression with no lived experience in that context.  Besides, why not both?

This is a social issue, so maybe it makes more sense to look at the 
social advantages and/or disadvantages of making (or not) the change and 
not focus so much on technical reasons.

Siddhesh

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Adhemerval Zanella]

On 31/01/2022 17:15, Siddhesh Poyarekar wrote:
> On 31/01/2022 23:39, Adhemerval Zanella via Libc-alpha wrote:
>> I must say that I am failing to see any technical advantage or improvement
>> of doing this change.
>>
> 
> There's no technical advantage because it is not a technical issue to begin with.  In fact, rejecting the suggestion saying that there's no technical advantage sends the unsaid message that we don't care enough to give this social issue any more serious thought than trying to glean technical merit from it.
> 
> I personally have no lived experience about the master/slave nomenclature since I'm not from the USA and I'm not African/African-American.  I don't think we have any regular African or African-American contributors either who could share their experiences about how (or if) the nomenclature affects them.  We're a mostly white community with smidges of Asian for flavour, albeit geographically very diverse (perhaps our relative ignorance/indifference towards this mostly-American origin movement is because of the latter) so I don't think any of us can reasonably speak to this.
> 
> My personal impression is that mentorship/paid programs would do far more good than renaming things, but it's just that, a third person impression with no lived experience in that context.  Besides, why not both?> 
> This is a social issue, so maybe it makes more sense to look at the social advantages and/or disadvantages of making (or not) the change and not focus so much on technical reasons.

Is there really an issue? Because I tend to agree with D.J where it seems 
to be more a ideological view from a very narrow group from a specific
geography than a broad discussion that fits in a multicultural community
such ours.  

I give you that it seems to be the trend in tech industry to use such 
language (as indicated by Carlos original email) but I personally thing it 
will most likely be innocuous to improve inclusiveness (there are far more 
pertinent problems such as mentorship as you posed).  I saw from our 
community experience that important changes such as a different leadership 
is a much more effective way to bring new contributors, so I tend to see 
this whole discussion as huge waste of effort and energy.

But personally I don't really care about the branch name, I just think that
if the idea is to improve the community inclusiveness, hinted by the original
motivation, there are more effective ways to do so.

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Siddhesh Poyarekar]

On 01/02/2022 02:54, Adhemerval Zanella wrote:
> Is there really an issue? Because I tend to agree with D.J where it seems
> to be more a ideological view from a very narrow group from a specific
> geography than a broad discussion that fits in a multicultural community
> such ours.

It's less ideology and more sensitivity IMO; in this specific case of 
renaming things I've seen people with aligned ideologies end up on 
opposite sides because of how much importance they put to the token gesture.

My argument is that because we're blind to the issue and how it's 
perceived by the target communities (i.e. African/African-Americans), 
our natural inclination would be to trivialize it, which may be to our 
peril.

> I give you that it seems to be the trend in tech industry to use such
> language (as indicated by Carlos original email) but I personally thing it
> will most likely be innocuous to improve inclusiveness (there are far more
> pertinent problems such as mentorship as you posed).  I saw from our
> community experience that important changes such as a different leadership
> is a much more effective way to bring new contributors, so I tend to see
> this whole discussion as huge waste of effort and energy.
> 
> But personally I don't really care about the branch name, I just think that
> if the idea is to improve the community inclusiveness, hinted by the original
> motivation, there are more effective ways to do so.

I'm inclined to agree, but if someone sees value in renaming (and if 
they're willing to do the work), I don't want to be in the way and if 
possible, help it along so that it causes minimal inconvenience.  If 
there's a net gain (e.g. if we end up with branch naming that is 
actually more descriptive, e.g. the "dev" that H J suggested) then it's 
even better.

Also since it's pretty much the standard in the tech industry now, 
opposing it would cause us more harm than good for a trivial reason.  As 
we say here in hindi, "khaya piya kuch nahi, glass toda baara aana" (We 
didn't eat or drink anything but had to pay for the glass we broke).

Siddhesh

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Florian Weimer]

* Siddhesh Poyarekar:

> I don't think we have any regular African or African-American
> contributors either who could share their experiences about how (or
> if) the nomenclature affects them.

I would like to point out that if you are wrong, such speculation can
make feel people marginalized because you tell them that they and their
contributions are not recognized.

Thanks,
Florian

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Siddhesh Poyarekar]

On 01/02/2022 15:19, Florian Weimer wrote:
>> I don't think we have any regular African or African-American
>> contributors either who could share their experiences about how (or
>> if) the nomenclature affects them.
> 
> I would like to point out that if you are wrong, such speculation can
> make feel people marginalized because you tell them that they and their
> contributions are not recognized.

I did not make that comment lightly and actually did look at (and 
recognize) practically every name in `git shortlog -ns` with over 100 
commits.  There's less than 50 of us in there; we're a much smaller 
community that you seem to think.

Even so, I don't deny the possibility of me having overlooked a name or 
two when I looked and I unconditionally apologize if I did indeed miss 
someone.

Siddhesh

Re: Rename "master" branch to "main" for glibc 2.35 release.

[Carlos O'Donell]

On 1/29/22 17:32, Carlos O'Donell wrote:
> In June 2020 I started this thread for glibc 2.32:
> https://sourceware.org/pipermail/libc-alpha/2020-June/115579.html
> to discuss a branch name change.
> 
> Thanks to Paul, Florian, Joseph and DJ who provided feedback on
> the initial discussion.

I'm going to take this feedback and start the process of migrating the scripts
to support "main" and include an alias for master.

I will start on the general plan outlined on the wiki:
https://sourceware.org/glibc/wiki/GlibcGit/MigrationToMain

The only difference is that I'm not going to put a timeline in place for
removal of the master symbolic-ref.

We also need to discuss if we want "release/2.35" branches or "release/2.35/main"
branches. As Florian and Dmitry point out it might be simpler to just use the
shorter name e.g. release/2.35. I would like to finalize that before glibc 2.36.

-- 
Cheers,
Carlos.