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

Stop using master/slave terminology #234

Closed
timj opened this issue Sep 27, 2017 · 9 comments
Closed

Stop using master/slave terminology #234

timj opened this issue Sep 27, 2017 · 9 comments

Comments

@timj
Copy link
Contributor

timj commented Sep 27, 2017

Can xdist please stop using the master/slave terminology? Would you accept a PR changing "slave" to "worker"? The terminology is upsetting to some people (and I've already had complaints where I work) and there is no reason to use it when other words exist that do not offend people. Words do matter.

@nicoddemus
Copy link
Member

Can xdist please stop using the master/slave terminology?

Definitely, we have already decided to use master/workers instead. Checkout the OVERVIEW for example.

The terminology is upsetting to some people (and I've already had complaints where I work) and there is no reason to use it when other words exist that do not offend people. Words do matter.

I understand, and I'm sure it was not the intention at all when it was written. I completely agree and understand why some people are offended by it. We did not however took the time yet to go over the code base changing the terminology.

Would you accept a PR changing "slave" to "worker"?

Definitely! Internally we can rename everything without any problem, but for flags (max-slave-restart for example) we should change to max-workers-restart but leave the old name in the code as to not break things (even if undocumented).

@RonnyPfannschmidt
Copy link
Member

This code is around since more than 12 years,
back then that was common terminology,

recent enhancements in understanding humans make a adoption of better names an important social responsibility,

However simple renaming isnt going to cut it as we need to preserve backward compatibility

Fortunately recent additions are already using the more respectful terminology

@timj
Copy link
Contributor Author

timj commented Sep 27, 2017

Are there public APIs that have "slave" in the name or are you talking about the command line options? (those would need to hang around as duplicates).

@RonnyPfannschmidt
Copy link
Member

For example slaveinput there is likely more

@RonnyPfannschmidt
Copy link
Member

I cant take a closer look until next week, im on a houseboat somewhere random atm

@nicoddemus
Copy link
Member

For example slaveinput there is likely more

@timj that's a dict which is inserted into the pytestconfig object in a worker process.

This can be probably changed to workerinput and a slaveinput added as an alias.

But indeed we will have to decide on a case-by-case basis. But if you want to start the PR @timj feel free to, we can review the parts which use the public API and decide on case-by-case the proper solution to each.

@nicoddemus
Copy link
Member

@RonnyPfannschmidt

im on a houseboat somewhere random atm

That's great! Enjoy your well deserved break! 😁 🍺

@feuillemorte
Copy link
Contributor

Please, review:

#268

nicoddemus added a commit that referenced this issue Feb 6, 2018
@nicoddemus
Copy link
Member

Closed by #268

Zac-HD added a commit that referenced this issue Jun 12, 2020
Zac-HD added a commit that referenced this issue Jun 12, 2020
Zac-HD added a commit that referenced this issue Jul 11, 2020
Zac-HD added a commit that referenced this issue Jul 11, 2020
Zac-HD added a commit that referenced this issue Jul 29, 2020
Zac-HD added a commit that referenced this issue Aug 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants