Open Stack

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.


-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
>  > 
>  > 
>  > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201124/7b377352/attachment.sig>