Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

evaluate a new primary branch name to replace master #7344

Closed
RonnyPfannschmidt opened this issue Jun 10, 2020 · 15 comments
Closed

evaluate a new primary branch name to replace master #7344

RonnyPfannschmidt opened this issue Jun 10, 2020 · 15 comments
Assignees
Labels
type: infrastructure improvement to development/releases/CI structure type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@RonnyPfannschmidt
Copy link
Member

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 Zac-HD added type: infrastructure improvement to development/releases/CI structure type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature labels Jun 10, 2020
@Zac-HD
Copy link
Member

Zac-HD commented Jun 10, 2020

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
Copy link
Member Author

@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
Copy link
Member

-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
Copy link
Member

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
Copy link
Member

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

@RonnyPfannschmidt
Copy link
Member Author

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
Copy link
Member

That should probably be a separate issue then, though?

@RonnyPfannschmidt
Copy link
Member Author

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

@RonnyPfannschmidt RonnyPfannschmidt self-assigned this Jun 10, 2020
@symonk
Copy link
Member

symonk commented Jun 11, 2020

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

@Zac-HD
Copy link
Member

Zac-HD commented Jun 11, 2020

@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
Copy link
Member Author

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

@symonk
Copy link
Member

symonk commented Jun 11, 2020

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

@RonnyPfannschmidt
Copy link
Member Author

@symonk indeed, a first step is to triage the occurrences into trivial, needing some work and needing a migration+break later

@Zac-HD
Copy link
Member

Zac-HD commented Jun 18, 2020

I think we have consensus against changing our default branch name at this time, and for removing "slave" references from our actual code.

I therefore suggest that we close this issue in favor of pytest-dev/pytest-xdist#541, which is tracking all the plugin changes - at this point the patches have all been written, it's just a matter of merging them and releasing the corresponding new versions!

@RonnyPfannschmidt
Copy link
Member Author

thanks, closing this one as sorted

i suspect we will revisit the main branch name in near future as there seems to be a emerging consensus of the branch name main
i plan to touch this after reviewing some early adopters/migrators

@Zac-HD Zac-HD closed this as completed Jun 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: infrastructure improvement to development/releases/CI structure type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

6 participants