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
@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