Richard Purdie <richard.pur...@linuxfoundation.org> writes:
>> > > > This script searches for a list of variable that have been renamed
>> > > > and converts them to their more descriptive names.
>>
>> s/descriptive/politically correct/
>
> We did try and make some of the names better describe what the variables
> do and make the variables more consistent.
>
> For example, a reference to HASHBASE was changed to BASEHASH which
> better matches every other reference to that thing in the code.
When you really feel that this Yoda style naming must be fixed; then ok.
But for me, the gain would not be large enough to break the api.
> The BB_ENV variables were also traditionally very confusing. Once you
> know, you know but for new users they weren't great.
The 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
things.
> Also see the discussion about the license variable issues. I'm very
> consciously blocking the "simple" change as I want to see things
> improve.
>
>> Variable names were perfectly readable. A change should make things
>> better, not worse.
>
> See above, there are at least some changes which do. I'm sad you don't
> agree.
ok; some changes are ok. E.g.
| "PNBLACKLIST":"SKIP_RECIPE",
because former name is misleading (it is not really a list/set but has
some specially addressing by varflags).
>> Why is the rename done at all? It makes the product just worse due to a
>> less usable api and because it causes a lot of work for the users of the
>> api (I shudder when I think about updating my CI to work with new and
>> old branches).
>
> For better or worse some of the terminology we have is offensive to
> some people.
Is there any real-world evidence that this is really the case? Especially
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 of
> something which someone could be offended by but these issues have
> come under a particular spotlight. People with far more experience of
> this than us have produced guidelines on the key issues,
In 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 do
> need to be open to and able to change. If we don't try and take this
> input and help those people make such changes where appropriate,
> we'll just alienate and frustrate more users even if those users
> were not personally offended by the language, a kind of "rot" can
> set in to our community. I do not want to see that
I 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 project
> get this wrong, the potential for negative social media feedback
> against the project is huge.
Does 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
feedback.
Just do the same here: avoid some terms in future development and when
there are really technical reasons to touch existing variables, then
rename them.
> For me personally, there is also a huge risk should I "misstep" in
> handling this. The potential to break things for users is also really
> high, I realise that. I have done a lot of work to try and make sure
> issues are at least clearly reported to users with some idea of how
> to resolve them so the transition is less painful. I do have some
> experience of making changes to the project and am trying my best to
> use that to our benefit.
You 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.
Enrico
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161950):
https://lists.openembedded.org/g/openembedded-core/message/161950
Mute This Topic: https://lists.openembedded.org/mt/89199536/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
