Terminology

[brezal]

If I created a pull request which changed the terms "master" and "slave" to "manager" and "worker", respectively, would it be pulled?

Reasoning:

1. I can see how these terms make a person, whose culture has a history of slavery, uncomfortable.
2. It would help me when discussing these topics with my team.
3. It makes me uncomfortable using these names in a public space.

I understand the PC culture is off putting, but this change would be of tremendous help to me.

Manager only adds one more character to type.
Worker only adds one more character to type.

[mboes]

While the intention is laudable and it's a point that everyone should keep in mind for future projects, retaining backwards compatibility is something we take pretty seriously. Surely for the purpose of discussing entities within your team you can use the words that you like if existing ones don't suit you?

[brezal]

@mboes Thank you for responding.
I find it difficult to refer to master slave node topology as anything other than what is currently listed in the documentation, because often I will ultimately have to make clear what exactly is being referenced. Maybe a change in terminology could be put into the next major release, since this type of release is expected to change existing behavior. Thoughts?

[qnikst]

There are a number of tickets in issue tracker that will break backwards compatibility and needs to happen in the next major release:

• Add "cookie" or other identification mechanism to SimpleLocalnet #17 - will break binary compatibility
• Re-export runProcess and forkProcess in SimpleLocalnet #16 - is backwards compatible but provides a way to use d-p-simplelocalnet without master/slave / manager/worker
• [DPSLN-5] The SimpleLocalnet backend should take (RemoteTable -> RemoteTable) rather than RemoteTable #10 - breaks backwards compatibility
• [DPSLN-1] simplelocalnet: how to use on master with several interfaces? #14 - nice to have, but it will require changes in deeper layers and possibly will break compatibility

So if #10, #16, #17 will be done this will be a good ground for the next major release anyway, and in my personal opinion, this issue can be resolved together with that, of cause with documentation update, so changes will be consistent. However current speed of changes is quite low so I'm not sure I can give good estimates about when this would happen. If someone would volunteer to do that work in may be done and would.

P.S. if this will happen one problem that still remains is that Simon's Marlow book still (and will always be) mentioning current terminology, and at least hardcopy versions could never be updated. This will add some additional problems to the readers.
P.P.S. Though I'd be happy to hear feedback from d-p-simplelocalnet users, and I know that there are such.

[hyperthunk]

+1 in principle.

[hyperthunk]

@brezal any reason why you closed this?

[brezal]

@hyperthunk I thought +1 in principle ≡ I agree, but it isn't going to happen.

I will be thrilled if this is not the intended interpretation.

[hyperthunk]

No no, I think we should do this! Sorry for the misunderstanding. I think from every perspective I cam see this is a good move, and backwards compatibility can be maintained by having a page on the website/wiki/docs that explains the change and why we made it.

[hyperthunk]

I should point out this isn't one of the projects I hold maintainership over in the github organisation though, so it's ultimately not my decision. But I do agree it's worthwhile and will be going through all the distributed-process-X projects I do maintain to apply the same principles.

[facundominguez]

IMO, it would suffice to mention the old names in the haddock of the renamed functions, and in the website a footnote on any related materials.

[hyperthunk]

Similar issue addressed in Supervisor, here.