evaluate a new primary branch name to replace master

[RonnyPfannschmidt]

In light of the #BLM movement i bumped into https://twitter.com/mislav/status/1270388510684598272?s=19

As master in git appears to be inheritance from bitkeeper master/slave i think it's warranted that the complete pytest-dev org takes a bit of time to set up a new best practice

Cc @pytest-dev/core

[Zac-HD]

I'm +0 on changing our default branch, because there's a lot of tooling and many tutorials that assume the default branch name is master. So while it would definitely be good for some, it would also make life a bit more difficult for new contributors.

On the other hand, there are still places where slave appears in Pytest and some of our first-party plugins; and that seems a lot worse to me - and has fewer downsides to fixing it. So my proposal is to:

• note our in-principle support for a new default branch name
• change the default branch name when a standard alternative to master has appeared
• prioritize the removal of "slave" in all existing pytest code and docs across our organisation
  i.e. git grep slave should not return any results outside old changelog entries - https://github.com/search?q=user%3Apytest-dev+slave&type=Code indicates we have a lot to do on this 😬

[RonnyPfannschmidt]

@Zac-HD thanks for the input

I like your proposal to immediately sort the details in our own code and deferring the git setup until a broad consensus emerged from the broader community

[The-Compiler]

-1, for various reasons:

• It will break a lot of tooling, and, perhaps more importantly, people's expectations
• From Twitter: The problem I see with that thread (and the dozen other I’ve seen on “git master”) is it’s all white people being eagerly offended on behalf of black people and acting like they need to bulldoze ahead and pad the walls as if the assumption black people are too fragile.

I do believe language is important and shapes reality - but I see it as a trade-off between benefits and drawbacks. Does saying "Hey everyone" instead of "Hey guys" change things for the better with no drawbacks? Absolutely, that's why I always try to do so (and point it out to people, if needed). Here, I doubt there's anyone affected (i.e. non-white) who would actually have a problem with that term (though I'd be happy to change my mind if someone steps up), yet it causes a lot of unnecessary frictions for contributors and developers.

[asottile]

If we had a branch or tech named "slave" I'd be 100% for switching off of that terminology (for example pytest-dev/pytest-xdist#268), though I'm not convinced that "master" on its own is insensitive and should warrant a change. I also echo @The-Compiler's reasoning for tooling breakages -- this'll cause significant pain for all of the workflows that I use right now which make assumptions about the primary branch being master. Then again, I don't feel like I'm the right person to be making a decision here.

[nicoddemus]

I agree with @The-Compiler, @asottile and @Zac-HD on all fronts mentioned.

[RonnyPfannschmidt]

i'm happy with all the input, i think as overall approach we should primarily concern ourselves with removing "slave" from our code

as for renaming branches we can reevaluate that if the rest of the opensource world develops some consensus on what to do and how to migrate,

[The-Compiler]

That should probably be a separate issue then, though?

[RonnyPfannschmidt]

Yes, I'll create issues as appropriate this evening or tommorow

[symonk]

Hi @RonnyPfannschmidt happy to help if you want to share a compiled list of areas that could use some changes

[Zac-HD]

@symonk - https://github.com/search?q=user%3Apytest-dev+slave&type=Code has some results - when I have a few hours my plan is to clone one of the plugin repos, git grep slave, and either delete each instance or replace it with worker (as we did in pytest-xdist several years ago).

Where it's already deprecated in favor of worker, as in pytest-xdist, IMO this is a good time to finish that process by removing the compatibility attributes.

I also want to be careful about drafting the changelogs, so that we clearly express (a) our support for diversity, (b) that this is not a new move for our project - rather finishing a years-long process, and (c) exactly what the technical impact will be (hopefully very small).

[RonnyPfannschmidt]

I'd be delighted to see that come down, im currently with family and might not get to it until the weekend

[symonk]

I guess this is quite problematic in the sense that some references are function args, any downstream code calling such functions by keyword= would break (in the instance of pytest-services from the link above); so possibility for quite a few 'breaking' changes by the time its all refactored. Will try do an indepth search and see how it looks