Open Stack

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 at ghanshyammann.com>
wrote:

>  ---- On Tue, 24 Nov 2020 12:58:47 -0600 Matthew Treinish <
> mtreinish at 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 at 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&files=tox.ini&excludeFiles=&repos=
>
> -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 at redhat.com>
> wrote:
>  > >  >
>  > >  >
>  > >  > --
>  > >  >                   Arx Cruz
>  > >  >                           Software Engineer
>  > >  >                   Red Hat EMEA
>  > >  >                               arxcruz at 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 at 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
>  > >  >
>  > >  >
>  > >  >
>  > >
>  >
>
>

-- 

Martin Kopec

Software Quality Engineer

Red Hat EMEA <https://www.redhat.com>

<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210105/c975b466/attachment-0001.html>