Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
Alexander Kanavin 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=de=halt=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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161381): https://lists.openembedded.org/g/openembedded-core/message/161381 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
On Fri, 4 Feb 2022 at 19:39, Enrico Scholz 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161380): https://lists.openembedded.org/g/openembedded-core/message/161380 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
Bryan Evenson 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] -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161377): https://lists.openembedded.org/g/openembedded-core/message/161377 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
Enrico, > -Original Message- > From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Enrico Scholz via > lists.openembedded.org > Sent: Friday, February 4, 2022 9:16 AM > To: Alexander Kanavin > Cc: Jon Mason ; Yocto-mailing-list > ; Patches and discussions about the oe-core > layer ; OpenEmbedded > Devel List > Subject: Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE > > Alexander Kanavin 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161367): https://lists.openembedded.org/g/openembedded-core/message/161367 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
Alexander Kanavin 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161365): https://lists.openembedded.org/g/openembedded-core/message/161365 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
On Fri, 4 Feb 2022 at 14:21, Enrico Scholz via lists.openembedded.org wrote: > "Jon Mason" 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161346): https://lists.openembedded.org/g/openembedded-core/message/161346 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Inclusive Language Proposal for YP/OE
"Jon Mason" 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161344): https://lists.openembedded.org/g/openembedded-core/message/161344 Mute This Topic: https://lists.openembedded.org/mt/88650128/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Inclusive Language Proposal for YP/OE folllow-up
This is a follow up to the Inclusive Language email I sent out on January 24 (see https://lore.kernel.org/yocto/capoiz9wl16otzxnhdw_5-l72gohkhhm0--wzf7an071cx6s...@mail.gmail.com/). I'm adding a couple of additional mailing lists to this email that were not on the original distribution, in case there are developers for those areas which didn't see the original email. I really appreciate the positive feedback received on this. I've updated the wiki with the suggested changes by Ross (acked by Randy) and Mikko, and extrapolated that to be the following list: CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE -> CVE_CHECK_SKIP_RECIPE CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE -> CVE_CHECK_IGNORE INHERIT_BLACKLIST -> INHERIT_RECIPESKIP -> INHERIT_RECIPE_SKIP SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE -> ESDK_LOCAL_CONF_REMOVE If anyone wants to nack the changes above, please let me know (or modify https://wiki.yoctoproject.org/wiki/Inclusive_language). Similarly, I've added all of the proposed names to the "approved name" column. On the same wiki, I've changed the tables to now have a volunteer developer column (from the "Assigned Developer" name) to make it more clear that we need help in doing these tasks. If there is anything you are interested in, please feel free to put your name down there and have at it. Thanks, Jon -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161329): https://lists.openembedded.org/g/openembedded-core/message/161329 Mute This Topic: https://lists.openembedded.org/mt/88899292/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Inclusive Language Proposal for YP/OE
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
Re: [OE-core] Inclusive Language Proposal for YP/OE
On Tue, 2022-01-25 at 07:50 -0800, Chuck Wolber wrote: > On Mon, Jan 24, 2022 at 8:18 AM Jon Mason 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.gitgitgad...@gmail.com/ The idea is we're trying to use the language which makes sense and "devel" says what the branch is/does. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160947): https://lists.openembedded.org/g/openembedded-core/message/160947 Mute This Topic: https://lists.openembedded.org/mt/88650128/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
On Tue, 25 Jan 2022 at 15:50, Chuck Wolber 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.gitgitgad...@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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160944): https://lists.openembedded.org/g/openembedded-core/message/160944 Mute This Topic: https://lists.openembedded.org/mt/88674712/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Inclusive Language Proposal for YP/OE
On Mon, Jan 24, 2022 at 8:18 AM Jon Mason 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.gitgitgad...@gmail.com/ ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160942): https://lists.openembedded.org/g/openembedded-core/message/160942 Mute This Topic: https://lists.openembedded.org/mt/88650128/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Inclusive Language Proposal for YP/OE
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.
[OE-core] Inclusive Language Proposal for YP/OE
>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.
