[qa][tempest] Update language in tempest code base
Hello,
I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist. We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives. As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side.
Any thoughts? Shall I start with a sepc, adding deprecation warnings?
[1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst
Kind regards,
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com wrote ----
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated naming conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting new names for new things we code.
For me, naming convention are the things which always can be improved over time, none of the name is best suited for everyone in open source. But we need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again changing in future.
At least from Tempest perspective, blacklist is very known common word used for lot of interfaces and dependent testing tool. I cannot debate on how good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in past but end up not-successful. Example: - https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a7...
-gmann
Any thoughts? Shall I start with a sepc, adding deprecation warnings?
[1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst Kind regards,
-- Arx Cruz Software Engineer Red Hat EMEA arxcruz@redhat.com @RedHat Red Hat Red Hat
On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated naming conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting new names for new things we code.
For me, naming convention are the things which always can be improved over time, none of the name is best suited for everyone in open source. But we need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again changing in future.
At least from Tempest perspective, blacklist is very known common word used for lot of interfaces and dependent testing tool. I cannot debate on how good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in past but end up not-successful. Example: - https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a 7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though. We could always add new interfaces and keep the old ones are deprecated (but not advertised) for the foreseable future. The old code won't be broken and the new one would use the new terminology, I'd say it's a good solution.
Yes, that's the idea.
We can keep the old interface for a few cycles, with warning deprecation message advertising to use the new one, and then remove in the future.
Kind regards,
On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano ltoscano@redhat.com wrote:
On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com
wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this
as
well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated naming conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting new names for new things we code.
For me, naming convention are the things which always can be improved
over
time, none of the name is best suited for everyone in open source. But we need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again changing in future.
At least from Tempest perspective, blacklist is very known common word
used
for lot of interfaces and dependent testing tool. I cannot debate on how good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in past
but
end up not-successful. Example: -
https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a
7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though. We could always add new interfaces and keep the old ones are deprecated (but not advertised) for the foreseable future. The old code won't be broken and the new one would use the new terminology, I'd say it's a good solution.
-- Luigi
---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz arxcruz@redhat.com wrote ----
Yes, that's the idea. We can keep the old interface for a few cycles, with warning deprecation message advertising to use the new one, and then remove in the future.
Deprecating things leads to two situations which really need some good reason before doing it:
- If we keep the deprecated interfaces working along with new interfaces then it is confusion for users as well as maintenance effort. In my experience, very less migration happen to new things if old keep working.
- If we remove them in future then it is breaking change.
IMO, we need to first ask/analyse whether name changes are worth to do with above things as results. Or in other team we should first define what is 'outdated naming conventions' and how worth to fix those.
-gmann
Kind regards,
On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano ltoscano@redhat.com wrote:
-- Arx Cruz Software Engineer Red Hat EMEA arxcruz@redhat.com @RedHat Red Hat Red Hat On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated naming conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting new names for new things we code.
For me, naming convention are the things which always can be improved over time, none of the name is best suited for everyone in open source. But we need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again changing in future.
At least from Tempest perspective, blacklist is very known common word used for lot of interfaces and dependent testing tool. I cannot debate on how good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in past but end up not-successful. Example: - https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a 7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though. We could always add new interfaces and keep the old ones are deprecated (but not advertised) for the foreseable future. The old code won't be broken and the new one would use the new terminology, I'd say it's a good solution.
-- Luigi
Well, at some point, it needs to break :)
I was for a long time maintainer of gnome modules, more specifically zenity and in order to move forward with some functionalities we had to break stuff. We could not keep legacy code and move forward with new functionalities, and the gnome strategy is pretty simple: minor version, you must maintain api compatibility. Major version, let's break everything! The user can either stay in the version X.y.z, or update their code to version X+1.y.z. That's exactly what happened when gnome/gtk released the 3.x version, and what will happen with the future 4.x version.
So, it's very hard to try new things, when you must maintain forever old things. The naming is for some people a problem, and we should make an effort to change that. Sometimes we don't see this as an issue, because it is so deeply rooted in our lives, that we don't see it as a problem.
I'll give you an example we have in Brazil: One of the biggest children authors, known as Monteiro Lobato [1], was a very racist person, and he put all his racism in books, the books we have to read at school. So, in one of his famous books he has this character called Tia Anastácia, and another one the smart one called Pedrinho. So, Pedrinho always calls Tia Anastácia as: "That black lady" or: She is as black as a Gorilla, and people thought this was fine, and funny. And it was an official lecture in schools in Brazil, and even had a TV Show about it. I was one of those who watched and read those books, and always thought this was OKAY. Today, my daughter will never read Monteiro Lobato, and hopefully she will understand that is wrong if people call you "black as a Gorilla", no matter the context. Now, imagine you grow up reading these stories, how would you feel? ;)
This is also right in code, you might not care, but there are people who are very sensible to some naming convention. Master/Slave may sound uncomfortable. Specially for people who have 400 years of slavery in their history. As an open source community, we should be able to fight against this, and make it a good code and environment for people who are new, and want to contribute, but not feel comfortable with some naming convention. You might say there's no such thing, but trust me they exist, and we should be working to make these people comfortable and welcome to our community.
It's not about breaking code, it's about fixing it :)
1 - https://en.wikipedia.org/wiki/Monteiro_Lobato
Kind regards,
On Thu, Jul 9, 2020 at 7:06 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz arxcruz@redhat.com wrote ----
Yes, that's the idea. We can keep the old interface for a few cycles, with warning
deprecation message advertising to use the new one, and then remove in the future.
Deprecating things leads to two situations which really need some good reason before doing it:
- If we keep the deprecated interfaces working along with new interfaces
then it is confusion for users as well as maintenance effort. In my experience, very less migration happen to new things if old keep working.
- If we remove them in future then it is breaking change.
IMO, we need to first ask/analyse whether name changes are worth to do with above things as results. Or in other team we should first define what is 'outdated naming conventions' and how worth to fix those.
-gmann
Kind regards,
On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano ltoscano@redhat.com
wrote:
-- Arx Cruz Software Engineer Red Hat EMEA arxcruz@redhat.com @RedHat Red
Hat Red Hat
On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote:---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com
wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their
more
inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on
this as
well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated
naming
conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting
new
names for new things we code.
For me, naming convention are the things which always can be improved
over
time, none of the name is best suited for everyone in open source.
But we
need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again
changing
in future.
At least from Tempest perspective, blacklist is very known common
word used
for lot of interfaces and dependent testing tool. I cannot debate on
how
good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in
past but
end up not-successful. Example: -
https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a
7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though. We
could
always add new interfaces and keep the old ones are deprecated (but not advertised) for the foreseable future. The old code won't be broken and
the
new one would use the new terminology, I'd say it's a good solution.
-- Luigi
On Thu, Jul 09, 2020 at 12:06:39PM -0500, Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz arxcruz@redhat.com wrote ----
Yes, that's the idea. We can keep the old interface for a few cycles, with warning deprecation message advertising to use the new one, and then remove in the future.
Deprecating things leads to two situations which really need some good reason before doing it:
- If we keep the deprecated interfaces working along with new interfaces then it is confusion for users
as well as maintenance effort. In my experience, very less migration happen to new things if old keep working.
Just a heads up the recent stestr 3.1.0 release (https://github.com/mtreinish/stestr/releases/tag/3.1.0) did this first step and deprecated things with:
https://github.com/mtreinish/stestr/pull/297
There were multiple recent user requests to start this process sooner rather than later. So regardless of what timetable and decision we make for tempest's interfaces we should probably update tempest's internal stestr api usage to reflect the new interface sooner rather than later (it will require bumping the min stestr version to 3.1.0 when that change is made).
- If we remove them in future then it is breaking change.
For stestr my plan is to make this breaking change eventually as part of 4.0.0 release. The exact timetable for that I'm not clear on yet since we try to avoid making breaking changes. The previous 2 backwards incompatible changes were removing python 2 support (which was 3.0.0) and switching to cliff for the cli, which wasn't strictly backwards incompatible we just made it 2.0.0 as a precaution because there were potential edge cases with cliff we were worried about. So there really isn't a established pattern for this kind of deprecation removal. I don't expect it to be a quick process though.
-Matt Treinish
IMO, we need to first ask/analyse whether name changes are worth to do with above things as results. Or in other team we should first define what is 'outdated naming conventions' and how worth to fix those.
-gmann
Kind regards,
On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano ltoscano@redhat.com wrote:
-- Arx Cruz Software Engineer Red Hat EMEA arxcruz@redhat.com @RedHat Red Hat Red Hat On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated naming conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting new names for new things we code.
For me, naming convention are the things which always can be improved over time, none of the name is best suited for everyone in open source. But we need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again changing in future.
At least from Tempest perspective, blacklist is very known common word used for lot of interfaces and dependent testing tool. I cannot debate on how good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in past but end up not-successful. Example: - https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a 7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though. We could always add new interfaces and keep the old ones are deprecated (but not advertised) for the foreseable future. The old code won't be broken and the new one would use the new terminology, I'd say it's a good solution.
-- Luigi
---- On Tue, 24 Nov 2020 12:58:47 -0600 Matthew Treinish mtreinish@kortar.org wrote ----
On Thu, Jul 09, 2020 at 12:06:39PM -0500, Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz arxcruz@redhat.com wrote ----
Yes, that's the idea. We can keep the old interface for a few cycles, with warning deprecation message advertising to use the new one, and then remove in the future.
Deprecating things leads to two situations which really need some good reason before doing it:
- If we keep the deprecated interfaces working along with new interfaces then it is confusion for users
as well as maintenance effort. In my experience, very less migration happen to new things if old keep working.
Just a heads up the recent stestr 3.1.0 release (https://github.com/mtreinish/stestr/releases/tag/3.1.0) did this first step and deprecated things with:
https://github.com/mtreinish/stestr/pull/297
There were multiple recent user requests to start this process sooner rather than later. So regardless of what timetable and decision we make for tempest's interfaces we should probably update tempest's internal stestr api usage to reflect the new interface sooner rather than later (it will require bumping the min stestr version to 3.1.0 when that change is made).
- If we remove them in future then it is breaking change.
For stestr my plan is to make this breaking change eventually as part of 4.0.0 release. The exact timetable for that I'm not clear on yet since we try to avoid making breaking changes. The previous 2 backwards incompatible changes were removing python 2 support (which was 3.0.0) and switching to cliff for the cli, which wasn't strictly backwards incompatible we just made it 2.0.0 as a precaution because there were potential edge cases with cliff we were worried about. So there really isn't a established pattern for this kind of deprecation removal. I don't expect it to be a quick process though.
Thanks matt for the updates and providing new interfaces in stestr, It will surely help Tempest to move towards those new deprecate these interface/wording. As discussed in PTG/Forum for overall direction in OpenStack, I am ok to do similar changes in Tempest.
For branchless Tempest, as you mentioned we need to bump the min stestr version to 3.1.0 for all supported stable branches which are stein onwards for now. Hope that is fine from a requirement perspective.
We can move Tempest to new stestr 3.1.0 soon and project side usage of stestr in unit/functional tests runner is also not much. Seems only two repo: - https://codesearch.opendev.org/?q=stestr%20run%20--black&i=nope&file...
-gmann
-Matt Treinish
IMO, we need to first ask/analyse whether name changes are worth to do with above things as results. Or in other team we should first define what is 'outdated naming conventions' and how worth to fix those.
-gmann
Kind regards,
On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano ltoscano@redhat.com wrote:
-- Arx Cruz Software Engineer Red Hat EMEA arxcruz@redhat.com @RedHat Red Hat Red Hat On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz arxcruz@redhat.com wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist.We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives.As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of 'outdated naming conventions ' are they outdated from coding language perspective or outdated as English language perspective? I do not see naming used in coding language should be matched with English as grammar/outdated/new style language. As long as they are not so bad (hurt anyone culture, abusing word etc) it is fine to keep them as it is and start adopting new names for new things we code.
For me, naming convention are the things which always can be improved over time, none of the name is best suited for everyone in open source. But we need to understand whether it is worth to do in term of 1. effort of changing those 2. un- comfortness of adopting new names 3. again changing in future.
At least from Tempest perspective, blacklist is very known common word used for lot of interfaces and dependent testing tool. I cannot debate on how good it is or bad but i can debate on not-worth to change now. For new interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement in past but end up not-successful. Example: - https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a 7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though. We could always add new interfaces and keep the old ones are deprecated (but not advertised) for the foreseable future. The old code won't be broken and the new one would use the new terminology, I'd say it's a good solution.
-- Luigi
Hi,
following the stestr's example I proposed a change in Tempest: https://review.opendev.org/c/openstack/tempest/+/768583 Feel free to review and comment.
See also other proposed changes by following the 'inclusive_jargon' topic: https://review.opendev.org/q/topic:inclusive_jargon+(status:open OR status:merged)
Kind regards,
On Tue, 24 Nov 2020 at 20:56, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Tue, 24 Nov 2020 12:58:47 -0600 Matthew Treinish < mtreinish@kortar.org> wrote ----
On Thu, Jul 09, 2020 at 12:06:39PM -0500, Ghanshyam Mann wrote:
---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz arxcruz@redhat.com
wrote ----
Yes, that's the idea. We can keep the old interface for a few cycles, with warning
deprecation message advertising to use the new one, and then remove in the future.
Deprecating things leads to two situations which really need some
good reason before doing it:
- If we keep the deprecated interfaces working along with new
interfaces then it is confusion for users
as well as maintenance effort. In my experience, very less migration
happen to new things if old keep working.
Just a heads up the recent stestr 3.1.0 release (https://github.com/mtreinish/stestr/releases/tag/3.1.0) did this
first step
and deprecated things with:
https://github.com/mtreinish/stestr/pull/297
There were multiple recent user requests to start this process sooner
rather
than later. So regardless of what timetable and decision we make for
tempest's
interfaces we should probably update tempest's internal stestr api
usage to
reflect the new interface sooner rather than later (it will require
bumping the
min stestr version to 3.1.0 when that change is made).
- If we remove them in future then it is breaking change.
For stestr my plan is to make this breaking change eventually as part
of 4.0.0
release. The exact timetable for that I'm not clear on yet since we try
to avoid
making breaking changes. The previous 2 backwards incompatible changes
were
removing python 2 support (which was 3.0.0) and switching to cliff for
the cli,
which wasn't strictly backwards incompatible we just made it 2.0.0 as a precaution because there were potential edge cases with cliff we were
worried
about. So there really isn't a established pattern for this kind of
deprecation
removal. I don't expect it to be a quick process though.
Thanks matt for the updates and providing new interfaces in stestr, It will surely help Tempest to move towards those new deprecate these interface/wording. As discussed in PTG/Forum for overall direction in OpenStack, I am ok to do similar changes in Tempest.
For branchless Tempest, as you mentioned we need to bump the min stestr version to 3.1.0 for all supported stable branches which are stein onwards for now. Hope that is fine from a requirement perspective.
We can move Tempest to new stestr 3.1.0 soon and project side usage of stestr in unit/functional tests runner is also not much. Seems only two repo:
https://codesearch.opendev.org/?q=stestr%20run%20--black&i=nope&file...
-gmann
-Matt Treinish
IMO, we need to first ask/analyse whether name changes are worth to
do with above things as results. Or in other
team we should first define what is 'outdated naming conventions' and
how worth to fix those.
-gmann
Kind regards,
On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano ltoscano@redhat.com
wrote:
-- Arx Cruz Software Engineer Red Hat EMEA arxcruz@redhat.com
@RedHatRed Hat Red Hat
On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mannwrote:
---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz <
arxcruz@redhat.com> wrote
Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more
open and
inclusive project by eliminating outdated naming conventions
from
tempest codebase, such as blacklist, whitelist.We should take
the
opportunity and do our best to replace outdated terms with
their more
inclusive alternatives.As you can see in [1] the TripleO
project is
already working on this initiative, and I would like to work
on this as
well on the tempest side.
Thanks Arx for raising it.
I always have hard time to understand the definition of
'outdated naming
conventions ' are they outdated from coding language perspective
or
outdated as English language perspective? I do not see naming
used in
coding language should be matched with English as
grammar/outdated/new
style language. As long as they are not so bad (hurt anyone
culture,
abusing word etc) it is fine to keep them as it is and start
adopting new
names for new things we code.
For me, naming convention are the things which always can be
improved over
time, none of the name is best suited for everyone in open
source. But we
need to understand whether it is worth to do in term of 1.
effort of
changing those 2. un- comfortness of adopting new names 3. again
changing
in future.
At least from Tempest perspective, blacklist is very known
common word used
for lot of interfaces and dependent testing tool. I cannot
debate on how
good it is or bad but i can debate on not-worth to change now.
For new
interface, we can always use best-suggested name as per that time/culture/maintainers. We have tried few of such improvement
in past but
end up not-successful. Example: -
https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a
7f493b6086cab9/tempest/test.py#L43
That's not the only used terminology for list of things, though.
We could
always add new interfaces and keep the old ones are deprecated
(but not
advertised) for the foreseable future. The old code won't be
broken and the
new one would use the new terminology, I'd say it's a good
solution.
-- Luigi
On 2020-07-09 10:57:14 -0500 (-0500), Ghanshyam Mann wrote: [...]
I always have hard time to understand the definition of 'outdated naming conventions' are they outdated from coding language perspective or outdated as English language perspective?
[...]
It's a recently popular euphemism for words which make people uncomfortable. Unfortunately, rather than addressing the problem head on and admitting that's the primary driver for the change, it has become preferable to pretend that's not the impetus for wholesale replacements of established terminology (often in an attempt to avoid heated debate over the value of such changes).
Don't get me wrong, I think it's entirely reasonable to replace words or phrases which make people uncomfortable, and in many cases it's an opportunity to improve our terminology by using words which have direct meaning rather than relying on computer science jargon based on idiom and loose analogy. Even if this comes at the cost of some engineering effort, it can be a long-term improvement.
But let's not kid ourselves, we're replacing words because they're deemed offensive. It's disingenuous, even potentially insulting, to imply otherwise.
participants (6)
-
Arx Cruz
-
Ghanshyam Mann
-
Jeremy Stanley
-
Luigi Toscano
-
Martin Kopec
-
Matthew Treinish