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



--

Arx Cruz

Software Engineer

Red Hat EMEA

arxcruz@redhat.com   

@RedHat   Red Hat   Red Hat