Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Jesuiter, Henry (ALC NetworX GmbH)]

Hi,

in regard of „master at doing something“, what about „Stalwart“ instead of 
„Slave“? You can keep the abbreviation „s“ (as in „slave“ or „sink“), it refers 
to „follower“ as in „fan“ and even means „loyal“ (as for synchronisation).

The only drawback: It‘s very uncommon in technical context and therefore not 
really understandable (at least now).

Holen Sie sich Outlook für iOS

-
Unsere Datenschutzerklärung finden Sie 
hier. | See our Privacy Policy 
here.


Von: Richard Hill 
Gesendet: Friday, August 21, 2020 7:00:51 AM
An: 'Vladimir Oltean' 
Cc: linuxptp-devel@lists.sourceforge.net 
Betreff: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology


> But what is wrong with 'Master' - ie Master Craftsman, Master
> Boatmaker, Master Baker, therefore Master Clock.  And doesn't it
> correctly describe what it's function is ?

> What do you mean what's wrong with it? The same thing that is wrong with
> 'slave', of course. Which is one meaning of it. "But words have more
> than one meaning", I hear you say? Yes, sure, here is what the Oxford
> Learner's Dictionary has to say about the word 'slave':


If you want to find an alternate meaning you don't like for just about any 
word, you'll
probably find one.
The word Master doesn't require Slave. But one of the meanings of master is
"master at doing something " - in our case Master of having a very good time 
source.

Or are we to drop the word Master from society because some people may be 
offended by it ?
Maybe we should drop other words too - the dictionary is probably full of them.

I see no good reason to drop the term "PTP-Master"

Yes, Richard probably had his mind set already, but to me replacing 
Master/Slave with all
the
alternatives I've seen will just give newcomers to PTP a hard time to 
understand.



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Richard Hill]

> But what is wrong with 'Master' - ie Master Craftsman, Master
> Boatmaker, Master Baker, therefore Master Clock.  And doesn't it
> correctly describe what it's function is ?

> What do you mean what's wrong with it? The same thing that is wrong with
> 'slave', of course. Which is one meaning of it. "But words have more
> than one meaning", I hear you say? Yes, sure, here is what the Oxford
> Learner's Dictionary has to say about the word 'slave':


If you want to find an alternate meaning you don't like for just about any 
word, you'll
probably find one.
The word Master doesn't require Slave. But one of the meanings of master is
"master at doing something " - in our case Master of having a very good time 
source.

Or are we to drop the word Master from society because some people may be 
offended by it ?
Maybe we should drop other words too - the dictionary is probably full of them.

I see no good reason to drop the term "PTP-Master"

Yes, Richard probably had his mind set already, but to me replacing 
Master/Slave with all
the
alternatives I've seen will just give newcomers to PTP a hard time to 
understand.



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Jacob Keller]

On 8/20/2020 2:16 PM, Vladimir Oltean wrote:
> On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote:
>> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
>>
>>> What if the terms on which IEEE 1588 settles are not the terms in your
>>> mind ("source"/"sink")?
>>
>> Because linuxptp is widely deployed, what we do could very well
>> influence the committee work.
>>
> 
> Aren't there simpler ways to influence the 1588 working groups, like
> sending them a direct email? I don't think a significant number of them
> are subscribed to linuxptp-devel@lists.sourceforge.net.
> Which begs the question, if you already had your mind set on a
> particular list of euphemisms, and you weren't actually looking for a
> second opinion from this group, why send this RFC patch at all? You can
> commit changes to linuxptp without peer review at any time.
> 
> Also (and this might be not for me to understand), if you are:
> 
>> doubtful whether changing the wording of the 1588 standard will
>> actually have a positive effect on the world or not
> 
> then why pressure them in the first place to make this change?
> 

The expectation is that the standards committee will change the terms
one way or another in the future.

If we assume that the terms master and slave will be removed, and do not
like many of the alternative proposals, it makes sense to try and
influence them to choose proposals we do find more suitable.

Doing nothing may increase the probability that the standards committee
chooses terms that Richard clearly dislikes: (leader/follower, etc).

> Thanks,
> -Vladimir
> 


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Vladimir Oltean]

On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote:
> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
>
> > What if the terms on which IEEE 1588 settles are not the terms in your
> > mind ("source"/"sink")?
>
> Because linuxptp is widely deployed, what we do could very well
> influence the committee work.
>

Aren't there simpler ways to influence the 1588 working groups, like
sending them a direct email? I don't think a significant number of them
are subscribed to linuxptp-devel@lists.sourceforge.net.
Which begs the question, if you already had your mind set on a
particular list of euphemisms, and you weren't actually looking for a
second opinion from this group, why send this RFC patch at all? You can
commit changes to linuxptp without peer review at any time.

Also (and this might be not for me to understand), if you are:

> doubtful whether changing the wording of the 1588 standard will
> actually have a positive effect on the world or not

then why pressure them in the first place to make this change?

Thanks,
-Vladimir


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Vladimir Oltean]

On Thu, Aug 20, 2020 at 07:50:29PM +0100, Richard Hill wrote:
> the word 'Slave' needs to be dropped ASAP.
> Waiting for the official committee might be like watching paint dry.
> 

Sorry for being a bit thick here, but where is this sudden urgency
coming from?  It's been like this for many, many years.  It is in the
realm of things that could have been better in hindsight, but don't
really make any difference.

> But what is wrong with 'Master' - ie Master Craftsman, Master
> Boatmaker, Master Baker, therefore Master Clock.  And doesn't it
> correctly describe what it's function is ?

What do you mean what's wrong with it? The same thing that is wrong with
'slave', of course. Which is one meaning of it. "But words have more
than one meaning", I hear you say? Yes, sure, here is what the Oxford
Learner's Dictionary has to say about the word 'slave':

3. (specialist) a device that is directly controlled by another one.

https://www.oxfordlearnersdictionaries.com/definition/english/slave_1

So, there you go. It is illogical to be offended by the word 'slave' but
not by 'master'.

-Vladimir


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Richard Hill]

but rather replace
"slave" with "sink" starting right away.

> But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker, 
> Master Baker,
> therefore
> Master Clock.  And doesn't it correctly describe what it's function is ?

My plan is leave the "master" term in place for now.

'For now'?  I've not seen a term mentioned that comes anywhere close to being 
as good as
the current term.
If it isn't broke, don't fix it ?





___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Richard Cochran]

On Thu, Aug 20, 2020 at 07:50:29PM +0100, Richard Hill wrote:
> I'm all a bit lost here.  Perfectly understandable that the word 'Slave' 
> needs to be
> dropped ASAP.
> Waiting for the official committee might be like watching paint dry.

Agreed.  My plan is NOT to wait for the committee but rather replace
"slave" with "sink" starting right away.
 
> But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker, 
> Master Baker,
> therefore
> Master Clock.  And doesn't it correctly describe what it's function is ?

My plan is leave the "master" term in place for now.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Richard Hill]

I'm all a bit lost here.  Perfectly understandable that the word 'Slave' needs 
to be
dropped ASAP.
Waiting for the official committee might be like watching paint dry.

But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker, Master 
Baker,
therefore
Master Clock.  And doesn't it correctly describe what it's function is ?



-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
Sent: Donnerstag, 20. August 2020 19:07
To: Vladimir Oltean
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:

> What I don't get is where is the need for linuxptp to "take the lead" on
> this topic?

see next answer...

> What if the terms on which IEEE 1588 settles are not the terms in your
> mind ("source"/"sink")?

Because linuxptp is widely deployed, what we do could very well
influence the committee work.

> Will there be a third set of names for clocks
> and ports?

For anything that affects protocol correctness, then we'll map the
internal terms to the official ones.  However, if I'm not wrong, the
strings "master" and "slave" are not part of protocol at all.

> What about a sort of internationalization support in linuxptp, then
> anybody could call "master" and "slave" whatever they feel like.

That won't work for program identifiers.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Richard Cochran]

On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:

> What I don't get is where is the need for linuxptp to "take the lead" on
> this topic?

see next answer...
 
> What if the terms on which IEEE 1588 settles are not the terms in your
> mind ("source"/"sink")?

Because linuxptp is widely deployed, what we do could very well
influence the committee work.

> Will there be a third set of names for clocks
> and ports?

For anything that affects protocol correctness, then we'll map the
internal terms to the official ones.  However, if I'm not wrong, the
strings "master" and "slave" are not part of protocol at all.
 
> What about a sort of internationalization support in linuxptp, then
> anybody could call "master" and "slave" whatever they feel like.

That won't work for program identifiers.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Vladimir Oltean]

On Thu, Aug 20, 2020 at 08:25:39AM -0700, Richard Cochran wrote:
>
> I expect that the change in the IEEE standard and in the industry is
> coming.

So, yes, the IEEE 1588 committee has changed terminology before
("time-aware bridge" -> "time-aware relay") and may do so again, to
remove words that are out of fashion today. Then linuxptp could follow
suite, as it always has, supporting a new 1588 revision with a new set
of knobs.

What I don't get is where is the need for linuxptp to "take the lead" on
this topic?

> I will not enter a bike shedding debate about whether leader/follower
> sounds better or not.  I have picked source/sink because that makes
> most sense to me.

What if the terms on which IEEE 1588 settles are not the terms in your
mind ("source"/"sink")? Will there be a third set of names for clocks
and ports?

What about a sort of internationalization support in linuxptp, then
anybody could call "master" and "slave" whatever they feel like.

> However, it certainly won't hurt anybody to change the terms, and it
> is easy to do.

But if you need to mention during every email reply that you're not
really up for bikeshedding, this might in fact prove your free time is
hurt more than you intended to by finding replacement terms that please
everyone. That, in fact, is the whole problem. There's nothing
defendable about the word "slave", it's just what the IEEE 1588
standards committee used.

Thanks,
-Vladimir


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Richard Cochran]

On Thu, Aug 20, 2020 at 04:02:30PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 19, 2020 at 09:42:40AM -0700, Richard Cochran wrote:
> > 
> > In any case, this is just the kind of bikeshedding discussion that I
> > want to avoid.
> 
> But you are the one who asked for it, aren't you?

;^)
 
> I mean, yes, a slave is not only somebody who works for a master, but
> somebody who does so for free and against their will. Whereas digital
> entities don't really have a will, and therefore the term is
> inappropriately used. In that sense, I think 'subordinate' is the word
> you're looking for. Simple replacement and not as extravagant as
> 'sheep'.

My suggestion of "sheep" was meant to be sarcastic!
 
> That being said, 'master'/'slave' is a well-established technical
> terminology which has little to do with human slavery, mind you.

I appreciate this point... more below...

> I think you're going to have some difficulty fixing up config-visible
> options such as 'slaveOnly' (without breaking deployments, which you
> mentioned as one goal), so I'm not really sure what's the point, if
> "words of dubious moral value" are not completely purged from the code
> base.

So it is clear that the configuration will need to be stay in place
for the present, but it can be gradually replaced.  My idea is to add
"sinkOnly" as an alias and then eventually replace "slaveOnly" with
whatever the revision of the published standard mandates.
 
> In the end I believe it's a balance between what problems this change is
> solving, vs what problems it's creating.

At least in my mind, I don't associate the "loaded" terms with slavery
when used in the context of computer networking.  I am also doubtful
whether changing the wording of the 1588 standard will actually have a
positive effect on the world or not.  However, it certainly won't hurt
anybody to change the terms, and it is easy to do.  Thus I am willing
to make the change.

I expect that the change in the IEEE standard and in the industry is
coming.  The Linux kernel has already amended its coding style
guidelines.  For this project, I want to take the initiative and
switch to terminology that at least makes sense to me.  After all, I
will be the one who will have to stare at the source code for years to
come, and if I see "leader/follower", for example, it will drive me
crazy.

If I follow through on this change, then it will be a top-down
decision.  However, I put up this as an RFC in order to allow people
to air their opinions on the topic and gauge the community's response.

You brought up the point of whether to make the change at all, and I
think that is a valid question, but it is a different question from
the choice of the replacement terminology.

I will not enter a bike shedding debate about whether leader/follower
sounds better or not.  I have picked source/sink because that makes
most sense to me.

Thanks,
Richard




___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Jagmeet Singh Hanspal]

Let's take it easy on one another.

Initially it looks it is going towards humanoid rights, but it is different
than that (more than machines' will).
More towards sensitivities of the users/admin who'd read/use such terms day
in/out and associated sensibilities.

Unless it comes from standard, different people can choose similar but may
not the same terms, and in this project contributors can take initiative &
settle on something (doc, messages etc).

Regards,
Jagmeet

On Thu, Aug 20, 2020 at 6:34 PM Vladimir Oltean  wrote:

> On Wed, Aug 19, 2020 at 09:42:40AM -0700, Richard Cochran wrote:
> >
> > In any case, this is just the kind of bikeshedding discussion that I
> > want to avoid.
>
> But you are the one who asked for it, aren't you?
>
> I mean, yes, a slave is not only somebody who works for a master, but
> somebody who does so for free and against their will. Whereas digital
> entities don't really have a will, and therefore the term is
> inappropriately used. In that sense, I think 'subordinate' is the word
> you're looking for. Simple replacement and not as extravagant as
> 'sheep'.
>
> That being said, 'master'/'slave' is a well-established technical
> terminology which has little to do with human slavery, mind you.
> I think you're going to have some difficulty fixing up config-visible
> options such as 'slaveOnly' (without breaking deployments, which you
> mentioned as one goal), so I'm not really sure what's the point, if
> "words of dubious moral value" are not completely purged from the code
> base.
>
> In the end I believe it's a balance between what problems this change is
> solving, vs what problems it's creating.
>
> Thanks,
> -Vladimir
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>


-- 

Best Regards,
~
Jagmeet Singh Hanspal
~
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Vladimir Oltean]

On Wed, Aug 19, 2020 at 09:42:40AM -0700, Richard Cochran wrote:
> 
> In any case, this is just the kind of bikeshedding discussion that I
> want to avoid.

But you are the one who asked for it, aren't you?

I mean, yes, a slave is not only somebody who works for a master, but
somebody who does so for free and against their will. Whereas digital
entities don't really have a will, and therefore the term is
inappropriately used. In that sense, I think 'subordinate' is the word
you're looking for. Simple replacement and not as extravagant as
'sheep'.

That being said, 'master'/'slave' is a well-established technical
terminology which has little to do with human slavery, mind you.
I think you're going to have some difficulty fixing up config-visible
options such as 'slaveOnly' (without breaking deployments, which you
mentioned as one goal), so I'm not really sure what's the point, if
"words of dubious moral value" are not completely purged from the code
base.

In the end I believe it's a balance between what problems this change is
solving, vs what problems it's creating.

Thanks,
-Vladimir


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel