Replace 'master' branches with devel in collections

[jillr]

SUMMARY

There's an ongoing conversation in the larger Open Source world about use of the terms 'master' and 'master/slave' in technology and the ties those words have to the legacy of human chattel slavery.

https://blog.carbonfive.com/problematic-terminology-in-open-source/
https://www.dreamhost.com/blog/addressing-problematic-coding-terms-open-source-community/

We have a precedent with ansible/ansible not having a master branch and instead using 'devel'. In talking with several members of the community, we'd like to propose that all official/managed Ansible project repos use 'devel' instead of 'master', to make this change on our existing repos, and to adopt this as an official policy for repos that we manage. We recognize that policy changes are outside the scope of a single github issue, so would like to start here by updating our collection repos.

Implementation Notes
This issue has a lot of detail on how another project handled this.

We’d need to:
Create a devel branch that matches master.
Change the default branch to devel.
Change any CI that depends on the master branch to use devel.
Redirect PRs from master to devel.
Change any documentation that points or refers to master to use devel.
Delete master.

This octokit plugin may be helpful for this.

ISSUE TYPE

• Bug Report

[pabelanger]

I do agree that master/slave is issue in projects, and seen several make changes as a result. This is the first time I am seeing 'master' branch for inclusion. Do you have any existing examples of other projects that have made this change?

Given that 'master' is the default branch with git, I'm curious is upstream git community has started discussions around this too?

Regarding devel or develop, this is usually a different git workflow then master branch. Which may signal to people collections would follow that model. https://nvie.com/posts/a-successful-git-branching-model/

I'm not opposed to the change, on the CI side for zuul this will require some coordination but doable.

[emonty]

I commented on this and then deleted the comment because I realized I don't feel strongly enough about my position to stand behind it in an ongoing discussion.

[samccann]

git upstream is considering this - https://public-inbox.org/git/CAOAHyQx=+fM1FpAv+g3M+j7j4MgLJA03=MGFmXLvZcfJKAEpGg@mail.gmail.com/t/#u

The conversation is quite active right now so it is hard to say which way it will go (changing master or keeping it, but providing an easy way to use something else).

[jillr]

@pabelanger What we change to is definitely open to bikeshedding, devel seemed like a good starting place given the precedent. There are currently conversations about git/github defaults, and other projects have done this. There's also some evidence that way back in the history, use of master in git may have been based on the master/slave usage in bitkeeper.1,2

Quick search of other projects:
cli/cli#929
desktop/desktop#6478

1. https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html (fwiw, I haven't read this entire thread - just a reference point)
2. https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L223

[goneri]

The word master has several meaning. I've always thought master, in the git context, means original, like a master copy of a record. And it makes sense since it's in general the canonical branch. It's happen that the word means the same thing in french, so I've never thought about it much more.

[rebeccahhh]

prod might be a good alternative to folks not really digging the terminology devel

[samccann]

So my nickel - yes, it would be great if git changed, no it's not a requirement imo before we decide to change away from master for the git projects under our control. This isn't a requirement for all collections, but it is an approach we want on the collections we manage directly. It matches where ansible/ansible has been for a while now. And while it may be a subset of the tech community that finds the term master as questionable, it is something we can do to be more welcoming to a diverse community of contributors.

[pabelanger]

git upstream is considering this - https://public-inbox.org/git/CAOAHyQx=+fM1FpAv+g3M+j7j4MgLJA03=MGFmXLvZcfJKAEpGg@mail.gmail.com/t/#u

The conversation is quite active right now so it is hard to say which way it will go (changing master or keeping it, but providing an easy way to use something else).

Thanks for sharing! That is helpful to see what upstream is doing. I do agree with @goneri 'master' to me in git, is master record / master copy.

[omgjlk]

I'm not a person of color, so my opinion of whether or not master as a term is problematic or not doesn't really matter. It might cost me a fumble or two if the Ansible project's various repo branches change from master to something else. I already pay that cost when working on ansible/ansible. I get momentarily confused, chuckle, and move on with my life. It costs me very little to make that adjustment. It'll cost a little more, maybe, if all the ansible/ repos changed. But, I think I would like it more if they were all consistent. Having some with master and some with devel is confusing. The solution is to not move ansible/ansible to master, when people have identified that as problematic.

In short, I'm totally in favor of changing away from master and picking a standard to use across the Ansible organization. Change often comes from within.

[felixfontein]

As someone who learned the English words master and slave in an IT context (I'm not a native English speaker), I don't have personal issues with them. And I also agree that master in git is related to master copy and not the master/slave terminology. Still, since there are people who have a very good reason to not like the term master, I agree it's better to switch to something else. (I'd also suggest devel, since ansible/ansible uses it and my muscle memory got very much used to it.)

(Also, this debate is not new. I've seen it pop up multiple times in the past I think.)

[Andersson007]

For me personally it does not make much difference how the working branch will be called.
In my native language the word master means a person who does things perfectly, e.g. "a master of sword", "a master of karate", etc, that's it.
AFAIK in English it also has several meanings.
In short, in git we don't have any slave and obviously the word master doesn't imply anything related to slavery.
Anyway, it's not a big problem to use a branch with another name. it could be devel like in ansible-base.

[dagwieers]

Some people are offended by git as well, let's move everything over to bitbucket!

Or maybe we should invest in educating people instead? Context is everything.

[geerlingguy]

I've been biting my tongue on this issue, as I've seen it popping up on Twitter at least in the past day or so, and in the past whenever I've brought up questions around similar topics, I've learned it's easier to keep out of the conversation.

But my background is audio/video (where you have a 'master' record/copy that is used to make duplicates and you have people who are experts in 'mastering' sound), IT (where often there's a 'master' copy from which others are made, other times there's a 'master' (as in primary) entity (but with no connotation of a concurrent 'slave' or 'subservient' entity (as is also the case with git)), and philosophy, where 'master' is "someone who has displayed great 'mastery' of thing x". (Some of these usages were mentioned by others in the thread.)

I had never considered the use of 'master' in any of these contexts to have any association whatsoever with the concept in slavery of there being a master-slave relationship (though maybe you could argue that kind of connotation exists in some database documentation which does mention slaves/masters)—that is, until I noticed some people mentioning it on Twitter and here.

Basically, what I'm trying to say is what is the primary motivation for this change? I studied linguistic philosophy in college and also spent a bit of time studying the importance of language in shaping the mind, so I understand that words do matter... but I'm wondering if, in this case, there's much ado about nothing?

(Aside: There are dozens of other computing paradigms and current popular applications which would also need fairly broad-reaching changes if the end goal is to banish the term 'master' from our lexicon... and while 'it's hard' is not a reason not to do something good, I have to question the motivation behind the change.)

All in all, if I'm wildly off course here, please help me understand the context better. What little I know about this situation I've seen in this thread and in a couple Twitter conversations that popped up in my feed last night.

[AshtonDavis]

The Master/Slave paradigm frankly doesn't belong and needs to go. It doesn't necessarily even make sense - in many cases slaves are replicates or duplicates of a "master", but you wouldn't call a secondary recording copy a "Slave" copy. So I don't mourn its loss and I am 100% in favor of banishing it from all of its IT usage.

Master in terms of branch... basically here's where I come down on these issues. Does it bother me personally? No. Am I invested in the name? no. Does it bother me because it bothers other people? Yes. So, if people are saying it's a problematic term, and there is some pretty clear connotation to the term "Master" in general, then I'm also fine with erasing it entirely.

There aren't a lot of uses of the word "master" out there that don't include subservience or control of some kind, even in the recording context. Origin (taken, I know), Main, Trunk, Prod, Devel, etc are all much clearer and don't carry this connotation.

tl;dr: People who matter find it hurtful, let's kill it. We don't need it.

[samccann]

@geerlingguy - my goal here is to be an inclusive community, and as @AshtonDavis articulated much better than I did, part of that is to remove what can be a bothersome terminology to some.

[geerlingguy]

@samccann - That makes sense. In terms of practicality, we do use devel currently for ansible/ansible, but I'd be more in support of moving everything towards main as (a) that seems to make more sense, since development can happen on other branches besides devel, and (b) it seems like others in other communities are settling on that term.

[dagwieers]

The Master/Slave paradigm frankly doesn't belong and needs to go. It doesn't necessarily even make sense - in many cases slaves are replicates or duplicates of a "master", but you wouldn't call a secondary recording copy a "Slave" copy. So I don't mourn its loss and I am 100% in favor of banishing it from all of its IT usage.

That is because "master" in "master copy" has absolutely nothing to do with slavery or slaves. It means the original copy. Just like "master" in Git has absolutely nothing to do with slavery or slaves, it means the original branch. Context is everything.

The fact you have to drag slavery into the picture and fail to connect the dots proves how far-fetched this really is. Someone mentioned "it is a small change to make a point against racism", I wish that would settle the matter, but I think actions like this one are in vain. I wish things were that simple.

Next up is to forbid Star Wars because of scenes of slavery and because they have Jedi masters. It is a slippery slope if we let go of context and intentions, and if we have to avoid offending anyone at all cost.

I probably offended someone with this post too. I apologize, it wasn't personal.

tl;dr: Well intentioned, but misguided.

[AshtonDavis]

Thanks for the input Dag.

The point about the music industry was actually mostly me dismissing it from the conversation.

In this instance, calling repos, servers, etc "slaves" is just problematic. There's a history to it, it's a metaphor/idiom that gets used frequently in public life ("crack the whip", "slavedriver", common phrases in business), and it bothers people who have suffered historical, personal, and cultural traumas.

I'm not going to entertain the conversation about Star Wars. This conversation is about Ansible, and I think generally speaking we're making the right effort to create an inclusive community.

[resmo]

Because I was quoted, I have to make my point clear (context is everything): I may get political on twitter but not in tech.

I have doubts changing "master" to something less "loaded" would make a difference (but I hope I'll be wrong). I usually avoid technical decisions initiated by political reasons. Changing the default branch name for whatever good reason to something else would be rather small, arguing against it would be a waste of time. But, I don't see a technical need for this change or policy.

I learnt the terms "slave" or "master/slave" in tech 20 years ago and my context to these terms is tech. To me, "master" in git was never meant to offense anyone and I agree, context is important. But, as I non-colored, non-native English speaking person, I have to agree, it is not my privilege to judge if "master" offenses anyone.

[AshtonDavis]

Dag, I suggest you accept that you have stated your opinion and move on. Thanks.

[cpitre]

As person of color, I see both points of view; the internal meaning used within git vs. the negative meaning. I have used various source code repository tools starting from CVS and VSS, and moved on to ClearCase, Subversion and Git. BitKeeper (Master repository) and VSS (Master project) did name the tool's Repository pattern name (see Software Configuration Management Patterns, Effective Teamwork, Practical Integration, Stephen P. Berczuk with Brad Appleton, pages 174 and 179). No matter what we decide I would like the documentation to refer to:

• reference(s) / links on how/where the naming nomenclature/conventions originated
• the fact that we understand the negative connotation of words (master/slave)
• we're having discussions on what to do about it, and welcome input
• anything else?

See how another tool's community has been handling it: jenkins.
Informing our producers/consumers would be a good start.
It will also show that the community is aware and is sensitive to those of us who may have concerns about these type of topics.

[dagwieers]

@cpitre The word "slave" has ever only had one meaning, "master" has countless of meanings in today English:

• https://www.google.com/search?q=define:%20slave
• https://www.google.com/search?q=define:%20master → Press "All"

I don't think you can compare both cases and pretend they are the same thing IMO.

[cpitre]

@dagwieers I'm not comparing the two. In fact this whole conversation is about how do we handle these types of wordings. It's about being sensitive to what we know offends others. We know this to be true.
Whether we do something (in the future) or not, I think the first step could be documenting the context of how the wording is used. It would be helpful to those that have a concern about it. My preference is to not use it, and replace it with devel or main. If it is not changed people can still read why it wasn't.
It's not solving the bigger problem, but it shows that we know that it may offend others. Saying something about (documenting it) is better than not doing anything, or ignoring it all together, which is THE problem in and out of tech.

[ssbarnea]

That made me laugh,... or cry, not sure. As one smart guy said once, there are only two infinite things out-here, but we are still debating about one of them.

Until git itself or github does such a switch forget it. We have far bigger issues to deal with, including bad behaviours.

That reminded about another move to obliterate use of whitelist/blacklist in various projects, one that caused lots or breakages. At least that one had a bit better reasoning behind.

One more thing: whatever you propose, always think about the implied costs, short and long term.

[dagwieers]

@ssbarnea I agree, I would prefer to see what Git and GitHub decide to use and go with that.

I proposed to use "master" many years back for ansible/ansible just because most people are used to using that and we were alienating ourselves from a common practice. Back then (before this was an issue) the main reason for not switching then was the impact it had for no real gain.

So if we change, let's hope we move to a common practice and not invent our own again.

[jillr]

Thanks very much @cpitre for your thoughtful comments. We wanted to make this proposal as a place to start having these conversations, and begin documenting folks’ different perspectives.

As for other terms, we do want to address them as well. Replacing whitelist/blacklist is a significantly larger undertaking for Ansible with much larger impacts to users and the community. So we saw that as a proposal for the future, that we could address on the momentum and learnings of this effort.

@ssbarnea If there are bad behaviours happening in the community now, Ansible is governed by a Community Code of Conduct. If folks are acting in violation of the CoC, or if the CoC is insufficient to address behaviours that are causing people harm, we definitely want to know about that. I’m available if anyone ever needs to discuss something, I’m also jillr on freenode and my email is that at redhat dot com.

I disagree that we need to “forget it” unless or until Git and/or Github act. It‘s great to see that they are also having this conversation, so since they are I can agree with the idea to wait to decide a branch name to see what they go with, which I think is what @dagwieers is suggesting. But I don’t think we should wait to decide whether or not to act.

Generally speaking, I have no desire or inclination to wait for someone else with a better majority presence to decide that we should begin making changes to make Ansible a more welcoming and inclusive place. Just because something is a norm doesn't mean it's always the best choice.

[bushvin]

I suggest we do not use the word 'devel' either, as 'devil' is derived from the old english word 'devel'
Worshipping people may be offended by the usage of that word.
ref: https://en.wikipedia.org/wiki/Devil

[nitzmahone]

It seems like the world is quickly converging on main, so if there's a significant desire to choose something quickly (and enough willing hands to go along!), that seems like a reasonable standard. It's early enough that changing the collections repos we own/have significant influence over shouldn't cause too much grief for the folks that work with those repos every day.

Ansible's use of the nonstandard devel has always been a personal source of annoyance to me, so I wouldn't be sad to see it go... I also think if it's going to happen for ansible/ansible, it should be on a stable branch fork boundary, which means either we do it when we branch 2.10 next week, or it happens whenever we branch 2.10++.

A cursory scan of the ansible/ansible codebase for blacklist/whitelist terminology finds several internal usages that should be trivial to change, but also several user-facing or API surface-area usages. I'm not personally opposed to changing those to something like denylist/allowlist, but that'll be a process, as we'd need a significant deprecation period on the existing names (our usual is 2y, and especially for the widely-used ANSIBLE_CALLBACK_WHITELIST it might need to be longer). Creating parallel behavior, names, and tests for those is a bit of work. We'd also need to decide what our deprecation warning messages and doc messages look like (eg, are we just saying "X is deprecated, use Y", or including inline explanation for the rationale (or a link to a more descriptive page on the docs site). If we decide to run with this, we need to figure out timing, and again, who's willing to pitch in on getting it done without breaking the world.

I personally think it's a Good Thing and I'm willing to pitch in.

EDIT IMO the blacklist/whitelist changes are better focused on 2.10++, where we'd have time to settle on things like the deprecation warning text/length.

ANOTHER EDIT Depending on the timing of emerging standards for the name, I'd also be totally fine with devel everywhere- internal consistency outweighs the word choice for me. There was some discussion around changing devel with the move to ansible-base / 2.10 (for unrelated reasons), but we ultimately dropped the idea.

[jillr]

I agree with nitz that code-changes like for blacklist / whitelist should happen under a separate scope/proposal and after we branch 2.10.

A number of projects are making these changes under deprecation cycles, for example SpamAssassin (a project where the functions these terms represent are fundamental to even basic usage of the software). The important thing, IMO, is that we are having these discussions, make plans, and put those plans into action, not that we change everything right this exact second.

[omgjlk]

Of note, it is being discussed in upstream git itself.

[jillr]

Looks like github is starting to rename their own repos, to main. https://twitter.com/lgarron/status/1271212268294823938

[felixfontein]

I'm fine with both devel and main, but since some people seem to be offended by devel, and devel doesn't fit with some workflows, main sounds like the best choice.

[ssbarnea]

I would have a big laugh if one of my favourite projects https://github.com/psf/black would end-up changing its name due to current social movements.

[dagwieers]

We could apply the same reasoning to main. The fact that something is main means other things are not considered equal. This might be offensive to some too.

The first definition of main is chief in size or importance. A chief also means a ruler of people which is equally offensive.

Ethymologically it is unsound too, meaning have power

Maybe we ought to pick a word that has no meaning at all to avoid having the same discussion in a few years?

[rhysmeister]

@dagwieers I propose grdguntlwlsgohzceikrespuwjogjd. We'll probably offend someone in some far off alien civilization but, since human development of intergalactic travel is some way off, we should get away with it for now.

[gundalow]

Other project moving from master to main, and some other supportive discussion. https://twitter.com/simpsoka/status/1271230467417628672?s=19

[dagwieers]

After thinking this through I have identified other words that might be offensive, including:

• chain, chains (chaining commands, some modules have it in their name)
• property (connotation to buying and selling slaves as property)
• buy / sell (connotation to buying and selling slaves as property)
• lock / locked
• own, owning, owner
• trade / trading (used in e.g. tradeoffs)
• force / labour (connotation to forced labour)
• privilege / non-privileged
• abuse
• serve / service / servant
• commit / confine
• restrict
• bond (connotation to bondage)
• bind / bound / boundary
• child (connotation to child abuse)

Is there a more extensive list of words with similar connotations? If not, we should probably establish one.

[omgjlk]

If your response to folks identifying a word that is offensive to them, is to create a whole new list of a bunch of words you think SHOULD be offensive, I think you're not approaching the discussion in good faith. In fact, it's a great example of ad absurdum.

[bushvin]

This whole exercise to change terms/words is absurd. It is only done so people can go back to having a good feeling about themselves.
Changing the way you name resources doesn't help in fighting -in this case- racism (or intolerance in general).
Instead of changing words/terms, why not pledge to have a 0 tolerance vs all forms of discrimination. That would actually mean something.

[omgjlk]

This whole exercise to change terms/words is absurd. It is only done so people can go back to having a good feeling about themselves.
Changing the way you name resources doesn't help in fighting -in this case- racism (or intolerance in general).
Instead of changing words/terms, why not pledge to have a 0 tolerance vs all forms of discrimination. That would actually mean something.

If this were a pile of white people coming up with the idea to change the name, without any input at all, then I would agree with you. However it appears not. It appears that all over the industry there is feedback that the term master is a micro aggression, that it does not help diversity, inclusion, and belonging within the communities. Often this feedback is given privately, because of the very high risk of public pile on and shaming by people who might disagree with the term being offensive (clearly in evidence here).

There are people reporting that it is not a good term to use. We have within our power the ability to change the term. We can choose to listen to those people and change the term, or we can choose to ignore them and continue the status quo. The status quo hasn't worked very well for increasing diversity, inclusion, and belonging. I think I'd rather try something new.

[felixfontein]

@bushvin

Instead of changing words/terms, why not pledge to have a 0 tolerance vs all forms of discrimination. That would actually mean something.

I don't think there's an XOR here. You can change words/terms, AND pledge to have 0 tolerance for discrimination. Also, changing some terms is a lot easier than others. Renaming the master branch to something else (main, devel, ...) is something that can be done with a very low cost. So why not do it, AND do some more?

[dagwieers]

Hold your horses, new evidence is out there that the guy who picked those names (https://twitter.com/xpasky/status/1271477451756056577) chose it in the context of "master recording" (https://twitter.com/xpasky/status/1272280760280637441). I had hoped Linus would come out and set the record straight, but apparently this was after the inception of Git.

So we now know that the use of "master branch" is:

• not about slavery or master/slave terminology
• was not intended to offend
• any offence taken was misguided

Therefore can we stop the nonsense by making the "master branch" racist? It isn't, wasn't and never has been.

And as the author stated he thinks "main" and "upstream" give more meaning (over "master" and "origin"). So rather than changing words because people take offense (which is a slippery slope) we can change words because they make things clearer. Which is every documenter's first concern anyway.

I propose we let upstream (Git/GitHub) decide and leave it up to projects to follow that new default. Without the need to make this a philosophical or political statement. Which I think everyone can agree on.

[omgjlk]

As we debate this issue I suggest we all take a moment to read through this thread. It clarified some things I've felt in a better way than I could.

https://twitter.com/mislav/status/1270388510684598272?s=21

[letoams]

The argument of "your negative connotations around this harmless word are misguided" is pretty weak and misguided.
I can call my new protocol Web Heuristic Informational Transport Exchange (WHITE), and it will still be racist. My intention is not relevant. A black person who experiences structural racism, and that happens a lot in our societies, cannot avoid the impact of needing to talk about the WHITE protocol all the time.

The argument "but this is master without the slave" is irrelevant. It is inconsiderate. It is spoken from a privileged position. You cannot argue away how another group of humans feel about some terms, simply because you logically conclude something on their behalf based on a dictionary.

The cost of changing this is basically zero. There is no harm in doing this. Even if you disagree with the gains of this, erroring on the side of caution and compassion is the right thing to do. And because of this, putting your foot down about how this is wrong or meaningless and should not happen, can only be interpreted as malicious - and in this case becomes indistinguishable from racism.

At libreswan, we are going to rename the branch to "main". I'm sure I and our developers will get over this minor inconvenience and our muscle memory will pick it up soon enough.

As for the guy who picked these names, he said: "I have wished many times I would have named them "main" (and "upstream") instead. Glad it's happenning"

[geerlingguy]

It is inconsiderate. It is spoken from a privileged position. [It] can only be interpreted as malicious - and in this case becomes indistinguishable from racism.

I do not think I'd ascribe malicious intent to any pushback on this issue (or indeed many other things that are being debated currently). By saying that, it makes the situation turn even further from a discussion about "hey maybe we can do better by discussing terminology" to "this is right, you are wrong, and if you think it's not wrong you're a bad person", and then tempers flare very quickly, and logic removes itself entirely from discourse.

Anyways, I just want to say statements that inflame are one reason I personally decide to remove myself far from most of these discussions.

If you don't immediately toe the party line when it comes to certain changes in the name of D&I and/or the racism divide, then there are many people who start invoking privilege, pressure the person to be removed from places of power, etc., and I hate it when I see it because at a minimum, the way to get people on your side is to not label them a certain way, paint them in a corner, and call for ostracization. You're not solving the problem, and you're just taking a community that formerly excluded maybe three groups and now excluding four.

If someone can't see what you're seeing, guide them. If it becomes an issue that is in conflict with Ansible's Code of Conduct at some point, we can deal with it, but my goal is that we don't have to wield a CoC like some communities and put the hammer on some people (often people outside the US, it seems, who have a wildly different perspective on the issues we here in the US are always dealing with).

[rfc-2549]

I personally think it's a good idea to break a lot of scripts just because you don't like the word master.

[noahbliss]

A point I'd like to add, one I think we can all agree on, is that we're talking about code with these terms, not humans. Certain words are simply more optimal than others for describing the relationship between functions concisely and clearly.

An easy example that comes to mind is in automotive component nomenclature. "Master Cylinder", "Slave Cylinder", et cetera. In this example the slave cylinder is functionally controlled by the master cylinder's inputs. Again, no references to human slavery or a political agenda, but words chosen to effectively and concisely describe the function and relationship of the parts. Again, functionally, my car is a slave to me, and my body is a slave to the laws of physics. There is no social justice to be gained or lost in any of those cases, but "master" and "slave" remain a concise and accurate description of the relationship.

Other terms that are used but could be argued as troublesome include "sub, super, alpha, beta, dom, control, finger, clobber, man", but digging such terms up would have returns inverse the reasonableness of asking "Is rewriting the English language and depriving developers of concise labels really an effective social improvement for disadvantaged people?"

That said, like many others here I don't think "master" in git is even used as the master/slave relationship. Functionally, I see master as "main" or "base" with other branches often named descriptively for the feature or fix being implemented or generically such as "dev." But if we were having this conversation about any other standard (switching the HTTP standard port for example) the answer would be what it almost always is, acknowledgement that we may have been able to do better, but acceptance of what we picked for the sake of not breaking things. I believe this is the correct course in this case as well. When we deviate from this, we end up with fiascos like IPv6's adoption rate.

--

Logistics aside, there is another issue here though too, the seemingly insatiable need to "whitewash" (ironically enough not a racial term in origin or functional use in this case) internet and social culture to a degree that we deprive actual issues of their impact. Slavery in virtually every culture and nation was real and terrible up until a shockingly and uncomfortably recent era. The word is one that should be understood. I understand the master/slave relationship that I have with my car or computer. The understanding I have of that relationship's nature makes it all the more appalling when I imagine it between humans.

Tl;Dr "master" and "slave" are words that describes a relationship. It becomes inhumane only and especially when living beings are involved. Depriving the words of their correct usage handicaps the language's potential and prevents people a correct understanding of their application to history.

..."main" is fewer characters to type though, I'd prefer it. :P

EDIT: "root" or "trunk" would make a little more sense in the context of "branches" and still save a character too. I'd be team "root" if it were changed.

[felixfontein]

These technical terms stem from the use of human slavery. I really don't see any reason to continue using them, except human lazyness.

I personally think it's a good idea to break a lot of scripts just because you don't like the word master.

Can you name at least one script that is actually broken by this? If you would have mentioned contributors who already checked one of the repos out and is working on them, this would be a valid argument. Or existing links to files on GitHub in the master branch. But scripts? Seriously?

[ssbarnea]

All CI/CD pipelines and related scrips have special logic around master branch, the impact is huge for any project with history, including for some of its consumers which may clone its master branch.

Our Ansible Community is too small and fresh in order to start making rush decisions. That particular case is one where I would find the locked feature beneficial.

I propose closing and locking this topic not as wontfix but as delay any change until at least one major upstream project is making a similar move (git, github, python, ...). Luckily Ansible deviation saved them this joy).

Can we be bit more pragmatic and focus on things that really matter? Let few others bigger communities debate these and test the side effects of their decisions first.

I am going to unsubscribe now from this thread which proves to be a perfect flame-war, so tag me if I really need to read a reply.

[felixfontein]

Changing CI/CD pipelines is a simple one-time change. I'm mainly meaning "external" scripts which depend on this.

About "focus on things that really matter": IMO this does really matter. Otherwise I would not be participating in this discussing here.

[gundalow]

Hi all,

For those that don't know me, I'm part of the community team here at Ansible.

1. Thank you all for engaging with a difficult non-technical topic.
2. This isn't about what Bitkeeper or Git thought when naming things when they were created. It's about making this project more accessible and welcoming to a wider range of people.
3. We see that GitHub are moving from master to main.
4. Some of the discussion here has been that we shouldn't lead, and rather follow other larger projects (like GitHub).
5. Some have said we shouldn't need to wait.
6. We don’t gain anything by waiting for other projects to implement changes to begin doing so ourselves. Though we like that other communities are moving in the same direction.
7. Given (3),(4),(5),(6) we will be changing the default branches for github.com/ansible-collections/ to main. We will provide guidelines and details of impact.
8. The Ansible project stands with and for any and all under represented, oppressed, and marginalized members of our community.

We’d like to remind everyone that as we say in our Code of Conduct,

Every community can be strengthened by a diverse variety of viewpoints, insights, opinions, skillsets, and skill levels. However, with diversity comes the potential for disagreement and miscommunication. The purpose of this Code of Conduct is to ensure that disagreements and differences of opinion are conducted respectfully and on their own merits, without personal attacks or other behavior that might create an unsafe or unwelcoming environment.

These policies are not designed to be a comprehensive set of Things You Cannot Do. We ask that you treat your fellow community members with respect and courtesy, and in general, Don’t Be A Jerk. This Code of Conduct is meant to be followed in spirit as much as in letter and is not exhaustive.

An ongoing conversation at Ansible is how to create a community environment that is welcoming to new contributors. With the upcoming change from GitHub in regards to changing “Master” (potentially to something like “Main”) and the widespread racial equality protests across the world we at Ansible realized that now is a good time to examine some of our own language.

Ansible’s Code of Conduct states:

Every community can be strengthened by a diverse variety of viewpoints, insights, opinions, skillsets, and skill levels.

We stand by that. We want to create an environment in which people of different backgrounds and perspectives feel like their contributions are valued and welcomed, because they are. We need to make sure the community we foster reflects that Code of Conduct. To do this we are willing to examine both big and small changes and efforts that make our community better.

On that topic, while we welcome the discussion in this issue, there are a few items that are not acceptable:

• implying or saying people are stupid
• invalidating or disrespecting others opinions or experiences
• being generally dismissive or derisive
• attempting to dominate a discussion or drowning out other perspectives

This list of items are not within the spirit of our Community’s Code of Conduct and we would like to ask folks to be respectful and kind to each other. Keep in mind that we have folks from all over the world with different perspectives and no one should ever belittle other contributors or community members.

In regards to the change in default branch name. Many folks on this thread have argued that the use of “Master” in this context is not racist, and we recognize that the origin may or may not have been intended to be so. The semantic details of language matter less than the potential impact it may have, intended or otherwise. Proposing this verbiage change is a small move that will benefit some and will not actively harm others, therefore it is a change worth investing in, even if it is a small drop in the bucket that is the ocean we must address as a society.

We are reviewing and updating the Ansible codebase to replace blacklist/whitelist with denylist/allowlist. Documentation and examples will use the new terms by default. As Ansible already has a deprecation cycle, the old naming convention will continue to work till it's removed at the end of the deprecation cycle.

In addition to these small steps Red Hat as a whole has donated money to movements that support racial equality and matches associate donations to charitable organizations as well. While these two things are in no way equivalent (or sufficient), they are both progress. To make both big and small changes is important and while this may come across as a "Public Relations" move to some, please know that this change was driven by associates who desired the place in which they work to be a better place.

We are committed to creating a better contributing experience overall and if anyone has suggestions for how we can make contributing to Ansible a more welcoming experience, we gratefully accept suggestions and of course, improvements! We are an open source project and if there are things that you can do to make our community a better place we welcome those things. Please keep in mind our Community Code of Conduct and Happy Automating.

It should be noted even though I posted this reply, that these are the words of a lot of Ansible's staff.

You are free to reach out to me directly via gundalow (at) redhat.com, gundalow on Freenode regarding this, or anything to do with the wider Ansible Community.

[felixfontein]

BTW, one practical aspect of changing branches: at least in the collections I'm working with, there are links in galaxy.yml or README.md (and thus on Galaxy) which point to the collection's master branch on GitHub (f.ex. for docs, changelog, ...). So when we change the default branch from master to main (or whatever else), we should keep master around until the next release. (Or, alternatively, only rename branches shortly before a release.)

[geerlingguy]

@felixfontein - Another consideration, at least for a few, is to make sure to update any GitHub Actions workflows (or other CI tools) to make sure anything that ran on master would next run on main.

And this may be obvious to some, but make sure to switch the default branch in GitHub's settings for the repository, otherwise things like git cloneing without a commit ref will not get the main branch.