RE: [oe] [OE-core] Inclusive Language Proposal for YP/OE

[Bryan Evenson <bevenson@melinkcorp.com>]

Enrico,

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Enrico Scholz via
> lists.openembedded.org
> Sent: Friday, February 4, 2022 9:16 AM
> To: Alexander Kanavin <alex.kanavin@gmail.com>
> Cc: Jon Mason <jdmason@kudzu.us>; Yocto-mailing-list
> <yocto@lists.yoctoproject.org>; Patches and discussions about the oe-core
> layer <openembedded-core@lists.openembedded.org>; OpenEmbedded
> Devel List <openembedded-devel@lists.openembedded.org>
> Subject: Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
> 
> Alexander Kanavin <alex.kanavin@gmail.com> writes:
> 
> >> > For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN"
> would
> >> > become "HALT, NO_NEW_TASKS and "WARN".
> >>
> >> I am not an native english speaker, but for "HALT" I will have to
> >> think twice whether it will pause the operation or abort it.  I would
> >> stay at "ABORT" because it makes much more clear what happens.
> >
> > I'm not taking a stand here, but just providing the context for where
> > the push for avoidance of 'abort' comes from:
> > https://inclusivenaming.org/word-lists/tier-1/
> >
> > Keep in mind that for non-native english speakers none of these words
> > are emotionally charged; they're just terms.
> 
> Yes; these are terms.  But it should be possible to understand the meaning of
> these terms without using a special "inclusivenaming"
> dictionary.  Else, we could just use "A", "B" and "C" for the actions above and
> explain these "terms" in some documentation later.
> 

Would CANCEL be clearer to you than HALT?

> 
> >> > BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
> >> > BB_SETSCENE_ENFORCE_WHITELIST ->
> BB_SETSCENE_ENFORCE_IGNORE_TASKS
> >> > BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
> >> > MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
> >>
> >> The new variable names sound like boolean flags, not like lists.
> >
> > I'd say the context should make it clear that they are lists
> 
> It is bad when a context is required to understand the meaning of a variable.
> 
> And where do you see a context when local.conf contains
> 
> | BB_HASHCONFIG_IGNORE_VARS = "true"

Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more sense to you?

Bryan
> 
> 
> 
> Enrico