Motion to rename master branch

[nwf]

I'd like to propose that we use release instead of the somewhat problematic term master. dev can stay as dev.

[marcelstoer]

👎

instead of the somewhat problematic term master

What makes this problematic?

It would be very unusual and completely unexpected for a Git repo to not have a master branch. It's certainly doable, master is nothing but a globally respected convention, but I'm afraid of the consequences and I see no benefit.

[nwf]

https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1

For our repository, the name is, at the very least, indicative of the wrong thing: in most git projects, the master branch is the one from which the releases are cut, i.e., what we call dev.

[pjsg]

I thought that we cut releases from master. We do development on a long running dev branch that should be strictly a number of commits on top of the most recent master release. As I understand the normal release process is to do a monster PR from dev to master (which is fast-forward) and then tag master with the release version tag.

Some repos just do all the development on master, but this is problematic if you want to keep master always working, and even more problematic if you sometimes want to cherrypick important bug fixes onto master. If there are any bug-fixes that go onto master, then you do a merge from master into dev sometime before you do the release.

[marcelstoer]

@pjsg your observations in paragraph one are correct.

[nwf]

Look, I dare say I understand both how git works and how projects in general and in particular NodeMCU historically use git's features. Please give me some credit?

Our releases are just tags; tags in git are not attached to any branch, as they just point to a particular nodes in the commit DAG. (Indeed, branch heads are also just tags; commits do not "know" they are on a branch.) It happens that, yes, we always ensure that the so-designated commits occur on the (erroneously, problematically named) master branch, but we could expunge every reference to the master branch from git's data structures and our releases would still continue to name the existing objects.

We do not, in general, make releases with their own life-cycles; our master branch is (barring mistakes, in general) entirely quiescent between cut-overs from dev. Thus I'd say we cut releases from dev and they happen to end up on master. If we deliberately, separately evolved master in parallel to dev, then I'd say we cut releases from master, but we don't; master just serves (or is intended to serve) as a historical record of releases. Especially with the recent rebase-ing of dev atop master, we are unlikely to create merge commits going forward, so we could just as readily directly tag dev head for our releases when desired.

All I'm proposing is that we rename master to release to capture its true use in the existing flow and move us away from antiquated terminology. This is not technically challenging, poses no real long-term risk to the project (a few search-and-replace bumps to scripts, perhaps, and existing clones needing to update), and is following in the footsteps of other progressive open source projects.

(For more about the history, the curious are welcome to read https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html, which has primary sources. In summary, tho': the name master came to git via CVS but mostly BitKeeper, where it was used to mean the master/leader repository, since BK doesn't differentiate between branches and repositories. master in that sense was the primary integration branch, i.e., what we call dev.)

[TerryE]

Surely master isn't hardwired anywhere except in preconceptions and conventions. Especially given the current social climate, I feel that we should be more sensitive to the IETF Terminology guidelines.

[pjsg]

I buy the argument about the current social climate.... I'll go for release

[marcelstoer]

Surely master isn't hardwired anywhere except in preconceptions and conventions.

We'll only ever find out once we change it and folks come back with complaints - or not. We'll be breaking everybody's local clone of this repository. We'll be breaking every NodeMCU automation script out there, ours(?) and others. We'll be breaking every NodeMCU fork. We'll likely be breaking every PR. We'll be breaking every single reference to https://nodemcu.readthedocs.io/en/master/. And there may be more that I haven't thought of.

I do understand the motivation behind this and @nwf's description of the Git details is certainly accurate (he sure understands Git better than I do). However, I feel what we gain isn't worth the pain we'll be inflicting. Couldn't it be that the number of people who are negatively affected by this change is much larger than the number of people who actually care about the semantics behind the name of our default branch?

Side note, there's a nice blog post by @shanselman about the rename procedure to follow at https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

[TerryE]

@marcelstoer, you point out some valid impediments which could create a DoS for other users and projects referencing to ours. Nonetheless I feel that we should still support Nathaniel's goal here. There must be a lot of other projects considering how to respond the IETF draft Terminology Guidelines. In the case of ReadTheDocs, what we need is a 301 redirector for en/master to en/release which isn't currently standard functionality. Maybe we should first post an issue to ReadTheDocs pointing them to the IETF document, and asking how they will facilitate this.

[marcelstoer]

There must be a lot of other projects considering how to respond the IETF draft Terminology Guidelines.

Indeed, the IETF draft cites a number high-profile cases; Python being the most prominent one. On the other hand it's just a draft. It wasn't accepted as a "recommendation" (or more) and thusly expired a year ago. There are high-profile projects that refused to change their master/slave terminology; Redis is one of them. IMO they would potentially have had even more reason to change as in my understanding of English and in my mother tongue the term "slave" (not the subject here) has a much worse connotation than "master". The way I read the IETF draft, "master" is only(?) an issue if used as part of the master-slave terminology but not in itself.

One day Git/GitHub might acknowledge that IETF draft and provide a mechanism to rename branches in a transparent way i.e. so that a git pull/fetch/whatever will apply the change to a local clone. Until then I don't support this motion. It goes without saying that I'll certainly accept any decision by the majority of the maintainers.

[pjsg]

See also https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/

[TerryE]

as in my understanding of English

Slavery was rarely a material economic factor within Europe and it was largely illegal by the early 1800s. Class exploitation was a far more dominant social factor, so the word 'master' therefore has a class / hierarchical context across the EU, rather a racial one; the US economic history is quite foreign to this. However, given the global IT sector and the leading role that US plays, I feel that we should acknowledge the racial resonance of the US coinage of "master" and be sensitive to it.

Edited to removed much of this comment because this was a personal view and outside the scope of this project

[nk2IsHere]

From the creators of The Main and Margarita by M. Bulgakov, The MainCard, and Main's degree.(C)

I really hope that you have written this here just because of white-black hype.
Seriously, though, is there any rational arguments for this renaming contraversy?

[nwf]

@nk2IsHere Yes, as stated above, our use of master is, from a purely technical perspective, inconsistent with the intended semantics of its name, thus we seem to be in agreement about moving to release.

This is a strange issue to choose to be your (apparently) first point of interaction with our project. I'd hate to think you were engaging in bad faith or deliberately searching for this particular controversial topic and posting in an effort to wind people up.