Inclusive Language Proposal for YP/OE

Inclusive Language Proposal for YP/OE

[Jon Mason]

From the beginning, OpenEmbedded and The Yocto Project have always
strived to be as inclusive as possible to all races, sexes,
orientations, religions, nationalities, and any other thing which
might divide people.  As continuation of this striving, there are
suggested changes below that are being proposed to make the projects
more inclusive and show the community as the professional, friendly,
and welcoming group that it is.   There are words in use by the
projects directly or one of its derivative layers that could be
offensive to some.  For more information on which words we selected
and why, please consult
https://inclusivenaming.org/word-lists/overview/

In the process of changing these, we are using this opportunity to
make the terms more obvious and useful, as well as removing cruft and
other unused code.  This is the pure definition of a win-win solution.

With this in mind, a group of people have tried to identify issues and
come up with a plan to address these.   We’ve divided the tasks into 3
areas: bitbake variables, oe-core variables, and everything else.

Bitbake Variables
Taking issues in turn, for bitbake:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
become "HALT, NO_NEW_TASKS and "WARN".

BB_ENV_WHITELIST -> BB_ENV_PASSTHROUGH
BB_ENV_EXTRAWHITE -> BB_ENV_PASSTHROUGH_ADDITIONS

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
BB_STAMP_WHITELIST and BB_STAMP_POLICY -> delete the code (already merged)

basewhitelist and taskwhitelist as used in sigdata/siginfo will need
to be renamed and older file usage of the variables renamed at import
for backwards compatibility. The variables in bitbake along with usage
of abort will be renamed as appropriate.

For most variables, errors will be shown to the user if the old
variable names are set. Mostly this can be done in event hooks but
some like the BB_ENV changes will need special handling.

These changes hopefully improve consistency (e.g. a consistent BB_
prefix and BASHHASH as terminology used elsewhere) and also improve
the description of the variables to be more understandable to users.

OE-Core Variables
For OE-Core, the proposals are:

For blacklist.bbclass, the proposal is to add the functionality to the
anonymous Python in base.bbclass instead. PNBLACKLIST[xxx] would
become SKIP_RECIPE[xxx]. INHERIT_BLACKLIST would simply be dropped.

SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE
TUNEABI_WHITELIST - already removed as obsolete

For the ICECC_USER_XXX and ICECC_SYSTEM_XXX, we think these can likely
be merged into single variables:

ICECC_USER_CLASS_BL -> ICECC_CLASS_DISABLE
ICECC_SYSTEM_CLASS_BL -> ICECC_CLASS_DISABLE
ICECC_USER_PACKAGE_WL -> ICECC_RECIPE_ENABLE
ICECC_USER_PACKAGE_BL -> ICECC_RECIPE_DISABLE
ICECC_SYSTEM_PACKAGE_BL -> ICECC_RECIPE_DISABLE

For license handling, we’d use the opportunity to clean up the
WHITELIST_(ANY LICENSE) syntax and replace it with a
INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of recipes
which are of a blocked the INCOMPATIBLE_LICENSE list.

Everything else
The migration plan includes writing a script to assist with the
migration. In many cases it can likely make the translation. In cases
where that isn’t possible, it will aim to list the areas the user
needs to fix references.

A warning mechanism will be added to bitbake to detect usage of old
variable names (post parsing), except for BB_ENV issues which will
likely need special handling. A (limited) conversion script will be
created to help with the migration. For those instances where a 1-1
mapping is not achievable, a list of the occurrences and what it
should be changed to will occur.


Patch files in OE to be renamed:
11_tcpd_blacklist.patch -> 11_tcpd_blocklist.patch
mount.blacklist -> mount.disallow
0001-lxdm.conf.in-blacklist-root-for-release-images.patch ->
0001-lxdm.conf.in-deny-root-for-release-images.patch
022-RH-Remove-the-property-blacklist-exception-builtin.patch ->
022-RH-Remove-the-default-property-exception-builtin.patch
0001-Cargo.toml-do-not-abort-on-panic.patch ->
0001-Cargo.toml-do-not-exit-on-panic.patch
0004-Cargo.toml-do-not-abort-on-panic.patch ->
0004-Cargo.toml-do-not-exit-on-panic.patch
Also, there are a few others outside of OE that should probably be patched too.

Branch Names
The “master” branches on the relevant OpenEmbedded and Yocto Project
git trees will be changed to an alternative name at some point in the
future.  The current preferred name is “devel”.  There is no time
table for this currently, and there is no obligation or requirement to
change the branch name for any downstream project which is beyond the
project’s remit.

Similarly, there is no need to change any recipes that are using a
“master” branch as part of the SRC_URI.  Those are outside the scope
of YP/OE and this effort.

Note
These changes are only to bitbake and OE-Core.  There is no
requirement to change any other layers but we’d note consistency is
encouraged and helpful to users.

Helping
If you would like to help, please put your name by the items in
question on the inclusive language wiki page.
https://wiki.yoctoproject.org/wiki/Inclusive_language

Thanks
Special thanks to Richard Purdie, Michael Opdenacker. Marta
Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin
Kuster for providing their time, technical details, text, and feedback
on this task.

Re: Inclusive Language Proposal for YP/OE

[Paul Barker]

[-- Attachment #1.1.1: Type: text/plain, Size: 7066 bytes --]

On 24/01/2022 16:17, Jon Mason wrote:
>  From the beginning, OpenEmbedded and The Yocto Project have always
> strived to be as inclusive as possible to all races, sexes,
> orientations, religions, nationalities, and any other thing which
> might divide people.  As continuation of this striving, there are
> suggested changes below that are being proposed to make the projects
> more inclusive and show the community as the professional, friendly,
> and welcoming group that it is.   There are words in use by the
> projects directly or one of its derivative layers that could be
> offensive to some.  For more information on which words we selected
> and why, please consult
> https://inclusivenaming.org/word-lists/overview/
> 
> In the process of changing these, we are using this opportunity to
> make the terms more obvious and useful, as well as removing cruft and
> other unused code.  This is the pure definition of a win-win solution.
> 
> With this in mind, a group of people have tried to identify issues and
> come up with a plan to address these.   We’ve divided the tasks into 3
> areas: bitbake variables, oe-core variables, and everything else.
> 
> Bitbake Variables
> Taking issues in turn, for bitbake:
> 
> For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
> become "HALT, NO_NEW_TASKS and "WARN".
> 
> BB_ENV_WHITELIST -> BB_ENV_PASSTHROUGH
> BB_ENV_EXTRAWHITE -> BB_ENV_PASSTHROUGH_ADDITIONS
> 
> 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
> BB_STAMP_WHITELIST and BB_STAMP_POLICY -> delete the code (already merged)
> 
> basewhitelist and taskwhitelist as used in sigdata/siginfo will need
> to be renamed and older file usage of the variables renamed at import
> for backwards compatibility. The variables in bitbake along with usage
> of abort will be renamed as appropriate.
> 
> For most variables, errors will be shown to the user if the old
> variable names are set. Mostly this can be done in event hooks but
> some like the BB_ENV changes will need special handling.
> 
> These changes hopefully improve consistency (e.g. a consistent BB_
> prefix and BASHHASH as terminology used elsewhere) and also improve
> the description of the variables to be more understandable to users.
> 
> OE-Core Variables
> For OE-Core, the proposals are:
> 
> For blacklist.bbclass, the proposal is to add the functionality to the
> anonymous Python in base.bbclass instead. PNBLACKLIST[xxx] would
> become SKIP_RECIPE[xxx]. INHERIT_BLACKLIST would simply be dropped.
> 
> SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
> SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
> LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
> UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
> SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
> SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
> SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE
> TUNEABI_WHITELIST - already removed as obsolete
> 
> For the ICECC_USER_XXX and ICECC_SYSTEM_XXX, we think these can likely
> be merged into single variables:
> 
> ICECC_USER_CLASS_BL -> ICECC_CLASS_DISABLE
> ICECC_SYSTEM_CLASS_BL -> ICECC_CLASS_DISABLE
> ICECC_USER_PACKAGE_WL -> ICECC_RECIPE_ENABLE
> ICECC_USER_PACKAGE_BL -> ICECC_RECIPE_DISABLE
> ICECC_SYSTEM_PACKAGE_BL -> ICECC_RECIPE_DISABLE
> 
> For license handling, we’d use the opportunity to clean up the
> WHITELIST_(ANY LICENSE) syntax and replace it with a
> INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of recipes
> which are of a blocked the INCOMPATIBLE_LICENSE list.


This is an excellent proposal, the new variable names for bitbake & 
oe-core are clear and easy to understand.

> 
> Everything else
> The migration plan includes writing a script to assist with the
> migration. In many cases it can likely make the translation. In cases
> where that isn’t possible, it will aim to list the areas the user
> needs to fix references.
> 
> A warning mechanism will be added to bitbake to detect usage of old
> variable names (post parsing), except for BB_ENV issues which will
> likely need special handling. A (limited) conversion script will be
> created to help with the migration. For those instances where a 1-1
> mapping is not achievable, a list of the occurrences and what it
> should be changed to will occur.
> 
> 
> Patch files in OE to be renamed:
> 11_tcpd_blacklist.patch -> 11_tcpd_blocklist.patch
> mount.blacklist -> mount.disallow
> 0001-lxdm.conf.in-blacklist-root-for-release-images.patch ->
> 0001-lxdm.conf.in-deny-root-for-release-images.patch
> 022-RH-Remove-the-property-blacklist-exception-builtin.patch ->
> 022-RH-Remove-the-default-property-exception-builtin.patch
> 0001-Cargo.toml-do-not-abort-on-panic.patch ->
> 0001-Cargo.toml-do-not-exit-on-panic.patch
> 0004-Cargo.toml-do-not-abort-on-panic.patch ->
> 0004-Cargo.toml-do-not-exit-on-panic.patch
> Also, there are a few others outside of OE that should probably be patched too.
> 
> Branch Names
> The “master” branches on the relevant OpenEmbedded and Yocto Project
> git trees will be changed to an alternative name at some point in the
> future.  The current preferred name is “devel”.  There is no time
> table for this currently, and there is no obligation or requirement to
> change the branch name for any downstream project which is beyond the
> project’s remit.

The layer index may need some modification to handle different layers 
having different names for the in-development branch. We could implement 
the layer index changes first to support other layers which rename their 
master branch.

I'm going to bite the bullet with meta-linux-mainline and rename the 
master branch to "dev" this week to see what happens.

> 
> Similarly, there is no need to change any recipes that are using a
> “master” branch as part of the SRC_URI.  Those are outside the scope
> of YP/OE and this effort.
> 
> Note
> These changes are only to bitbake and OE-Core.  There is no
> requirement to change any other layers but we’d note consistency is
> encouraged and helpful to users.
> 
> Helping
> If you would like to help, please put your name by the items in
> question on the inclusive language wiki page.
> https://wiki.yoctoproject.org/wiki/Inclusive_language
> 
> Thanks
> Special thanks to Richard Purdie, Michael Opdenacker. Marta
> Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin
> Kuster for providing their time, technical details, text, and feedback
> on this task.
> 
Thanks all, it's great to see this moving forward!

-- 
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.barker@sancloud.com
w: https://sancloud.co.uk/

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7645 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Chuck Wolber]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Mon, Jan 24, 2022 at 8:18 AM Jon Mason <jdmason@kudzu.us> wrote:

%< SNIP %<


> Branch Names
> The “master” branches on the relevant OpenEmbedded and Yocto Project
> git trees will be changed to an alternative name at some point in the
> future.  The current preferred name is “devel”.
>

Why devel instead of main [1]?

[1]
https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgadget@gmail.com/

..Ch:W..



-- 
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*

[-- Attachment #2: Type: text/html, Size: 1170 bytes --]

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

[Ross Burton]

On Tue, 25 Jan 2022 at 15:50, Chuck Wolber <chuckwolber@gmail.com> wrote:
>> Branch Names
>> The “master” branches on the relevant OpenEmbedded and Yocto Project
>> git trees will be changed to an alternative name at some point in the
>> future.  The current preferred name is “devel”.
>
>
> Why devel instead of main [1]?
>
> [1] https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgadget@gmail.com/

Personally, the only advantage of 'main' is muscle memory of m[tab].

Semantically it's not the 'main' branch, it's the active development
branch.  Thus, devel.

Ross

Re: [oe] Inclusive Language Proposal for YP/OE

[Ross Burton]

On Mon, 24 Jan 2022 at 16:18, Jon Mason <jdmason@kudzu.us> wrote:
> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE

This is the only one that sticks out to me.  I think it needs another
_, SKIP_RECIPE and IGNORE_CVE.

Other than that, +1.

Will we have a bit of logic to detect the obsolete names being set and
emit warnings/errors?

Ross

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

[Randy MacLeod]

On 2022-01-24 11:17, Jon Mason wrote:
>>From the beginning, OpenEmbedded and The Yocto Project have always
> strived to be as inclusive as possible to all races, sexes,
> orientations, religions, nationalities, and any other thing which
> might divide people.  As continuation of this striving, there are
> suggested changes below that are being proposed to make the projects
> more inclusive and show the community as the professional, friendly,
> and welcoming group that it is.   There are words in use by the
> projects directly or one of its derivative layers that could be
> offensive to some.  For more information on which words we selected
> and why, please consult
> https://inclusivenaming.org/word-lists/overview/
> 
> In the process of changing these, we are using this opportunity to
> make the terms more obvious and useful, as well as removing cruft and
> other unused code.  This is the pure definition of a win-win solution.
> 
> With this in mind, a group of people have tried to identify issues and
> come up with a plan to address these.   We’ve divided the tasks into 3
> areas: bitbake variables, oe-core variables, and everything else.

Jon,

I've looked over all the changes and agree with Ross on his one suggestion
and that the rest of the changes are fine.


The new terms are equally or in some cases more clear so hopefully that 
will
result in less confusion and a better experience for everyone at the 
one-time
cost of a hopefully not too bumpy transition.

Thanks!

../Randy




> 
> Bitbake Variables
> Taking issues in turn, for bitbake:
> 
> For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
> become "HALT, NO_NEW_TASKS and "WARN".
> 
> BB_ENV_WHITELIST -> BB_ENV_PASSTHROUGH
> BB_ENV_EXTRAWHITE -> BB_ENV_PASSTHROUGH_ADDITIONS
> 
> 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
> BB_STAMP_WHITELIST and BB_STAMP_POLICY -> delete the code (already merged)
> 
> basewhitelist and taskwhitelist as used in sigdata/siginfo will need
> to be renamed and older file usage of the variables renamed at import
> for backwards compatibility. The variables in bitbake along with usage
> of abort will be renamed as appropriate.
> 
> For most variables, errors will be shown to the user if the old
> variable names are set. Mostly this can be done in event hooks but
> some like the BB_ENV changes will need special handling.
> 
> These changes hopefully improve consistency (e.g. a consistent BB_
> prefix and BASHHASH as terminology used elsewhere) and also improve
> the description of the variables to be more understandable to users.
> 
> OE-Core Variables
> For OE-Core, the proposals are:
> 
> For blacklist.bbclass, the proposal is to add the functionality to the
> anonymous Python in base.bbclass instead. PNBLACKLIST[xxx] would
> become SKIP_RECIPE[xxx]. INHERIT_BLACKLIST would simply be dropped.
> 
> SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
> SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
> LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
> UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
> SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
> SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
> SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE
> TUNEABI_WHITELIST - already removed as obsolete
> 
> For the ICECC_USER_XXX and ICECC_SYSTEM_XXX, we think these can likely
> be merged into single variables:
> 
> ICECC_USER_CLASS_BL -> ICECC_CLASS_DISABLE
> ICECC_SYSTEM_CLASS_BL -> ICECC_CLASS_DISABLE
> ICECC_USER_PACKAGE_WL -> ICECC_RECIPE_ENABLE
> ICECC_USER_PACKAGE_BL -> ICECC_RECIPE_DISABLE
> ICECC_SYSTEM_PACKAGE_BL -> ICECC_RECIPE_DISABLE
> 
> For license handling, we’d use the opportunity to clean up the
> WHITELIST_(ANY LICENSE) syntax and replace it with a
> INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of recipes
> which are of a blocked the INCOMPATIBLE_LICENSE list.
> 
> Everything else
> The migration plan includes writing a script to assist with the
> migration. In many cases it can likely make the translation. In cases
> where that isn’t possible, it will aim to list the areas the user
> needs to fix references.
> 
> A warning mechanism will be added to bitbake to detect usage of old
> variable names (post parsing), except for BB_ENV issues which will
> likely need special handling. A (limited) conversion script will be
> created to help with the migration. For those instances where a 1-1
> mapping is not achievable, a list of the occurrences and what it
> should be changed to will occur.
> 
> 
> Patch files in OE to be renamed:
> 11_tcpd_blacklist.patch -> 11_tcpd_blocklist.patch
> mount.blacklist -> mount.disallow
> 0001-lxdm.conf.in-blacklist-root-for-release-images.patch ->
> 0001-lxdm.conf.in-deny-root-for-release-images.patch
> 022-RH-Remove-the-property-blacklist-exception-builtin.patch ->
> 022-RH-Remove-the-default-property-exception-builtin.patch
> 0001-Cargo.toml-do-not-abort-on-panic.patch ->
> 0001-Cargo.toml-do-not-exit-on-panic.patch
> 0004-Cargo.toml-do-not-abort-on-panic.patch ->
> 0004-Cargo.toml-do-not-exit-on-panic.patch
> Also, there are a few others outside of OE that should probably be patched too.
> 
> Branch Names
> The “master” branches on the relevant OpenEmbedded and Yocto Project
> git trees will be changed to an alternative name at some point in the
> future.  The current preferred name is “devel”.  There is no time
> table for this currently, and there is no obligation or requirement to
> change the branch name for any downstream project which is beyond the
> project’s remit.
> 
> Similarly, there is no need to change any recipes that are using a
> “master” branch as part of the SRC_URI.  Those are outside the scope
> of YP/OE and this effort.
> 
> Note
> These changes are only to bitbake and OE-Core.  There is no
> requirement to change any other layers but we’d note consistency is
> encouraged and helpful to users.
> 
> Helping
> If you would like to help, please put your name by the items in
> question on the inclusive language wiki page.
> https://wiki.yoctoproject.org/wiki/Inclusive_language
> 
> Thanks
> Special thanks to Richard Purdie, Michael Opdenacker. Marta
> Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin
> Kuster for providing their time, technical details, text, and feedback
> on this task.
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#160881): https://lists.openembedded.org/g/openembedded-core/message/160881
> Mute This Topic: https://lists.openembedded.org/mt/88650128/3616765
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


-- 
# Randy MacLeod
# Wind River Linux

Re: [yocto] Inclusive Language Proposal for YP/OE

[Paul Eggleton]

On Tuesday, 25 January 2022 21:26:33 NZDT Paul Barker wrote:
> The layer index may need some modification to handle different layers 
> having different names for the in-development branch. We could implement 
> the layer index changes first to support other layers which rename their 
> master branch.
> 
> I'm going to bite the bullet with meta-linux-mainline and rename the 
> master branch to "dev" this week to see what happens.

The layer index does already support this, it's just not exposed (at the time 
I introduced it - some time ago - I thought it might encourage people to 
deviate from the release branch names, but in hindsight that was probably not 
worth worrying about.) So at the moment an admin can set an alternative branch 
name. It would not be hard to expose it through the UI for layer maintainers 
though.

Cheers,
Paul

Re: [oe] Inclusive Language Proposal for YP/OE

[Mikko.Rapeli]

Hi,

On Tue, Jan 25, 2022 at 04:30:40PM +0000, Ross Burton wrote:
> On Mon, 24 Jan 2022 at 16:18, Jon Mason <jdmason@kudzu.us> wrote:
> > CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> > CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
> 
> This is the only one that sticks out to me.  I think it needs another
> _, SKIP_RECIPE and IGNORE_CVE.

Please don't include CVE twice in the variable name, that's was annoying and just
got used to the CVE_CHECK_WHITELIST one. CVE_CHECK_IGNORE would do.

Cheers,

-Mikko

> Other than that, +1.
> 
> Will we have a bit of logic to detect the obsolete names being set and
> emit warnings/errors?
> 
> Ross

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#95071): https://lists.openembedded.org/g/openembedded-devel/message/95071
> Mute This Topic: https://lists.openembedded.org/mt/88650129/3616751
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [mikko.rapeli@bmw.de]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-devel@lists.openembedded.org <openembedded-
> devel@lists.openembedded.org> On Behalf Of Jon Mason
> Sent: den 24 januari 2022 17:18
> To: 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: [oe] Inclusive Language Proposal for YP/OE

[cut]

> For license handling, we’d use the opportunity to clean up the
> WHITELIST_(ANY LICENSE) syntax and replace it with a
> INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of 
> recipes which are of a blocked the INCOMPATIBLE_LICENSE list.

I am not so sure about this name. Not only is it extremely long, 
but at least I would like to revise the entire system of how 
licenses are handled. The major reason for this is that our 
legal department requires us to have a list of allowed licenses 
rather than a list of disallowed licenses. Thus we have a 
COMPATIBLE_LICENSES variable. We then set INCOMPATIBLE_LICENSE 
to AVAILABLE_LICENSES - COMPATIBLE_LICENSES. However, after the 
introduction of all official SPDX licenses into OE-Core a while 
ago this became problematic as the current implementation will 
go through all licenses specified in INCOMPATIBLE_LICENSE many, 
many times during recipe parsing, which caused the time to parse 
all recipes to increase three times for us. Thus I would like to 
implement proper support for COMPATIBLE_LICENSES in addition to 
the INCOMPATIABLE_LICENSE variable to allow choosing the option 
that suits the situation best.

However, in either case there would still need to be a way to 
specify exceptions to the incompatible licenses, which is why I 
would prefer that the name is not locked to the 
INCOMPATIBLE_LICENSE variable. Here are a couple of alternatives:

* LICENSE_EXCEPTIONS
* ALLOWED_RECIPES
* LICENSE_ALLOWED_RECIPES

It is also that the WHITELIST variables have two use cases today, 
one is to allow a _recipe_ to be built and the other is to allow 
a _package_ to be added to an image even if it has an incompatible 
license. The first use case can just as easily be achieved by 
setting INCOMPATIBLE_LICENSE:pn-foo = "" for a recipe foo that 
shall be allowed to be built even if it has an incompatible 
license. With this in mind, maybe the variable should actually be 
an image variable and specify a list of allowed packages instead, 
e.g., IMAGE_ALLOWED_PACKAGES. Whether the variable with a list of 
allowed recipes is then still needed or if it is enough to 
manipulate INCOMPATIBLE_LICENSE as per above can be discussed.

//Peter

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

[Enrico Scholz]

"Jon Mason" <jdmason@kudzu.us> 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.


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


> SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
> SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
> LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
> UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
> SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
> SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
> SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE

ditto; sounds like flags but not like lists


Enrico

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

On Fri, 4 Feb 2022 at 14:21, Enrico Scholz via lists.openembedded.org
<enrico.scholz=sigma-chemnitz.de@lists.openembedded.org> wrote:

> "Jon Mason" <jdmason@kudzu.us> 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. Not so for native speakers.


> > 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 (e.g. either
the initialization, or usage via iteration).

Alex

[-- Attachment #2: Type: text/html, Size: 2132 bytes --]

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

[Enrico Scholz]

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.


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



Enrico

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

[Bryan Evenson]

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

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

[Enrico Scholz]

Bryan Evenson <bevenson@melinkcorp.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.
>
> Would CANCEL be clearer to you than HALT?

mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.

I do not know how this can be described without using "abort" or some
extensively long terms.


>> >> > 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.
>
> Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more
> sense to you?

yes; it is much better.  But should it be an "IGNORELIST" or an
"IGNORE*D*LIST"?



Enrico
[who is irritated how people and especially developer can waste their
(and other developers) time in trying to change something which was
completely fine before]

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Fri, 4 Feb 2022 at 19:39, Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
wrote:

> > Would CANCEL be clearer to you than HALT?
>
> mmmh.... for me as a developer (and non-native english speaker), "cancel"
> means some ordered ending of an operation.
>
> But the condition above causes an emergency abort.
>

Cancel is the same as abort: a request to immediately stop the operation
(or not even start it) without reaching the originally requested outcome.

Halt implies the operation is not going to continue (Alan Turing was as
English as it gets, just to remind you).

I don't think any of this is remotely confusing.

Alex

[-- Attachment #2: Type: text/html, Size: 1077 bytes --]

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

[Enrico Scholz]

Alexander Kanavin <alex.kanavin@gmail.com> writes:

>> > Would CANCEL be clearer to you than HALT?
>>
>> mmmh.... for me as a developer (and non-native english speaker), "cancel"
>> means some ordered ending of an operation.
>>
>> But the condition above causes an emergency abort.
>>
>
> Cancel is the same as abort: a request to immediately stop the operation
> (or not even start it) without reaching the originally requested
> outcome.

https://english.stackexchange.com/questions/535153/what-is-the-difference-between-cancel-and-abort

| Cancel implies the action is rescinded before it implements...
|
| Abort is an emergency procedure to interrupt...


> Halt implies the operation is not going to continue

Really?

https://translate.google.com/?sl=en&tl=de&text=halt&op=translate says

| a suspension of movement or activity, typically a temporary one.

Examples in

      https://dictionary.cambridge.org/de/worterbuch/englisch/halt

sound like there is a chance to continue after the "halt" (show the
permit, resolve the pay dispute).


When we want to continue this inclusion BS, then "halt" seems to be
offending to some people because it can mean

| ... having a physical disability.



Enrico

Re: [oe] Inclusive Language Proposal for YP/OE

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Mon, Jan 24, 2022 at 5:18 PM Jon Mason <jdmason@kudzu.us> wrote:

> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
>

When running master-next I have found one missing rename, cve-check has
"CVE STATUS" result
which is still Patched, Unpatched, Whitelisted. I propose to rename
Whitelisted to Ignored to be in-line
with the variable rename.

Is there anyone using the states in scripting or other tools today?

Marta

[-- Attachment #2: Type: text/html, Size: 884 bytes --]