Richard Purdie <richard.purdie@...> writes:
When you really feel that this Yoda style naming must be fixed; then ok.We did try and make some of the names better describe what the variabless/descriptive/politically correct/This script searches for a list of variable that have been renamed
But for me, the gain would not be large enough to break the api.
The BB_ENV variables were also traditionally very confusing. Once youThe new naming is much more confusing. While this kind of operation
(exclude or include something) was previously named by "whitelist" +
"blacklist" more or less consistently, it is scattered around across
multiple variants now.
Especially for the hash related lists, searching for "whitelist" or
"blacklist" in the sources revealed often the right way how to do
Also see the discussion about the license variable issues. I'm veryok; some changes are ok. E.g.
because former name is misleading (it is not really a list/set but has
some specially addressing by varflags).
Is there any real-world evidence that this is really the case? EspeciallyWhy is the rename done at all? It makes the product just worse due to aFor better or worse some of the terminology we have is offensive to
the embedded sector is filled with blacklisted terms (i2c master/slave,
spi mosi/miso) so I do not think that somebody is really offended.
In the opposite, I feel offended when such changes are labeled as
(technical) improvements ("more descriptive names").
Obviously (and sadly) there will probably always be some element ofIn my experience, such people have too much spare time and invented a
problem only to come up with a solution later.
We do have people wanting to try and improve things. Projects doI see a much higher risk when significant changes are done due to
political reasons rather than technical ones.
I have advised caution all the way through this. Should the projectDoes such negative social media feedback really exist resp. does it
exist in channels that are relevant to us?
Linux kernel has not "cleaned" its api either and just said that future
development should avoid certain terms. I can not remember any negative
Just do the same here: avoid some terms in future development and when
there are really technical reasons to touch existing variables, then
For me personally, there is also a huge risk should I "misstep" inYou are doing a great job, but the project evolved beautiful over the
last >15 years with the old identifier and I can not remember any
complaints about them.