> On Jun 5, 2020, at 2:53 PM, Stephen Hemminger <step...@networkplumber.org>
> wrote:
>
> On Fri, 5 Jun 2020 19:23:52 +0000
> "Wiles, Keith" <keith.wi...@intel.com> wrote:
>
>>> On Jun 5, 2020, at 12:45 PM, Stephen Hemminger <step...@networkplumber.org>
>>> wrote:
>>>
>>> On Fri, 5 Jun 2020 17:10:05 +0000
>>> "Wiles, Keith" <keith.wi...@intel.com> wrote:
>>>
>>>>>>>
>>>>>>> I'd propose instead leader lcore - there is this idea that the leader
>>>>>>> is still a member of the team and will participate in the work.
>>>>>>>
>>>>>>> Leader / worker?
>>>>>>>
>>>>>>
>>>>>> I personally doubt such changes are needed at all.
>>>>>> Code churn will be massive for both DPDK itself and related user
>>>>>> projects.
>>>>>> With no real gain in return, from my perspective.
>>>>>> Konstantin
>>>>>>
>>>>>
>>>>> Your concern is valid but the issue does need to be addressed.
>>>>> If now when? This is as a good a time as any to do it.
>>>>>
>>>>> Increasing diversity and inclusion is an overarching goal of many
>>>>> organizations
>>>>> include my employer(Microsoft), the parent organization of DPDK(LF)
>>>>> and my values.
>>>>>
>>>>> Following values is more important than minor replacement of text in API.
>>>>>
>>>>
>>>> I feel like Konstantin is correct here.
>>>>
>>>> If we were using these terms for humans or groups of humans, then I would
>>>> agree they should be changed. We need to take into account the context of
>>>> the reference to these words. I agree some words should never be used in
>>>> any context, but these terms are very reasonable in the context of DPDK
>>>> and networking.
>>>
>>> Have to disagree, the words matter. This has been discussed many times.
>>> Please look at the footnotes from the Gnome post
>>>
>>>
>>> [0] -
>>> <https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt>,
>>> <https://twitter.com/justkelly_ok/status/933011085594066944>
>>>
>>> [1] - <https://github.com/django/django/pull/2692>
>>> [2] - <https://bugs.python.org/issue34605>
>>>
>>> [3] - <https://github.com/rust-lang-deprecated/rust-buildbot/issues/2>,
>>> <https://github.com/rust-community/foss-events-planner/issues/58>
>>>
>>> [4] - <https://twitter.com/ISCdotORG/status/942815837299253248>
>>> [5] - <https://gitlab.gnome.org/GNOME/geary/issues/324>
>>
>> You chopped off my last sentence in your reply.
>>
>> "If everyone wants to accept the code churn (and it will effect a large
>> number of applications, plus back porting will be more difficult IMO), then
>> we can do it."
>>
>> So to be clear, I am not opposed to making this change, but wanted to point
>> out the technical impacts of this change to DPDK as a whole.
>
>
> Thanks, my editing was not intended to be a way to stifling your response.
> How many applications try to support multiple DPDK major versions at once?
>
NP, I understand it was not intended, but wanted to make sure it was not lost.
In Pktgen I try to support back to 18.11 release and some have asked for 18.04,
one asked for 16.04 :-) I most likely do not do it very well, but I try given
the limited time I have.
The big churn happened in 19.05 I think when all of the APIs and defines
changed. It took me a few days to create a compat file to support backward
compatibility .
I try to tell everyone I only support the latest release of DPDK and latest
release of Pktgen, but that does not fly very well for some customers.
I would hope we can make this change and create methods to allow for supporting
backward compatibility without every application having to create the
compatibility support themselves.
Let me know how I can help,
Thanks
