From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADC54C433EF for ; Fri, 4 Feb 2022 13:58:47 +0000 (UTC) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) by mx.groups.io with SMTP id smtpd.web10.9180.1643983126630169743 for ; Fri, 04 Feb 2022 05:58:46 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=beApCesF; spf=pass (domain: gmail.com, ip: 209.85.222.51, mailfrom: alex.kanavin@gmail.com) Received: by mail-ua1-f51.google.com with SMTP id 60so11019793uae.1 for ; Fri, 04 Feb 2022 05:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I9khvmpK7OFeAR3nwiccLOM7kD/G215+b+bsOfzS2Vs=; b=beApCesFBEDcO4LP+dzAo1MavW+LfoJ83p18fIyvZmiYSOLpGPbr7uKnbwlxvHtI64 tqYvx1jGOFFRG0sHwD/gj84pE/ZxHZEV0X5DosVWBi691FWBTUE28Y1lfNJGPb/5XAid CJaJRwwNf8cGxzypYCTEm0OntzPBypeqobsXHrA2JPyBWeIRutNd5boTdZ+tS+AKVstB hvPg869eCv2yVfPWVInae/p4Ppfwm97l2waWEJZI9WNOepIYJBbp2IrNqjB3UQ/VoTTA JX42abHHRBbcUHVLMXSDs/t5uTkYeTyWlv36yJDdC3oisCIrLDTGIWZSG68lXt057tZ5 neaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I9khvmpK7OFeAR3nwiccLOM7kD/G215+b+bsOfzS2Vs=; b=8O8wJQw+EaFhqWFevhJgxHJvC9ZMRAakTKsma9gaKRXa/PC8ey+7abj+jLckX8th6Q J9C5w8Upm+hDZGQoIx0ujwELNLQB0n/iF2jsGwg/k5uTULR018VgzmGFfyjewC8AQL7V dT9Ea1DbdX3gkB+IEFoFM1hKfokHmDWTJMKzg4wrTFHSwYGTo5x93P+6n43oBdmgdph8 PNuqWBaxMG/HuOqbktuMiDcvKpkxqPe1kV+sVRUNSzOftw6kW2inMmG9xTd0kan439+i Lz44aFct56aqLvE5sPx2qwTflJedZb+/EV1WW5ng0/lG3e6/gQ9OJy96BfDFLicVKDGJ cT0A== X-Gm-Message-State: AOAM532BtDIsv5F3mcyKChxcs5WHVyuH0V9S/Iadv0xztvh2ptjFmkWR VQOKt3iTmYnGmv5mKSkEx4eCtC/8YasnlVcUmuU= X-Google-Smtp-Source: ABdhPJzNHBYwGKnsJj3gqxxzbo16iDKalKHmUbKCAbQTVXFoRSRKhetjV+LQ62p5nY7YTnVfIGoq8SCKeeubbviYRmI= X-Received: by 2002:a67:ce95:: with SMTP id c21mr911573vse.81.1643983125686; Fri, 04 Feb 2022 05:58:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Kanavin Date: Fri, 4 Feb 2022 14:58:34 +0100 Message-ID: Subject: Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE To: Enrico Scholz Cc: Jon Mason , Yocto-mailing-list , Patches and discussions about the oe-core layer , OpenEmbedded Devel List Content-Type: multipart/alternative; boundary="000000000000392c5f05d731a68a" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 04 Feb 2022 13:58:47 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/yocto/message/56069 --000000000000392c5f05d731a68a Content-Type: text/plain; charset="UTF-8" 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 --000000000000392c5f05d731a68a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 4 Feb 2022 at 14:21, Enrico Scholz via lists.openembedded.org <enrico.scholz=3Dsigma-chemnitz.de@list= s.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.=C2=A0 I would stay a= t
"ABORT" because it makes much more clear what happens.

I'm not taking a stand here, but just providi= ng the context for where the push for avoidance of 'abort' comes fr= om:

K= eep in mind that for non-native english speakers none of these words are em= otionally charged; they're just terms. Not so for native speakers.
<= /div>
=C2=A0
> 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

--000000000000392c5f05d731a68a--