Re: inclusive language

Armin Kuster

On 7/14/20 10:31 PM, Trevor Woerner wrote:

As most are aware, there are efforts in many open-source/free-software
communities to adjust the language that is used throughout a given project
to be more inclusive.

We discussed this briefly at the most recent YP Technical Team/Engineering
Sync Meeting. Many good points were raised. I'd like to start a discussion on
this topic via email in order to enumerate and keep track of these efforts.

1. As a project we need to decide whether or not to undertake this work. Not
all projects have decided to make any changes. The discussions we had at the
last meeting made it feel as though it was a forgone conclusion by those who
spoke up that we would take on this work. Is that the consensus? Silence
represents agreement?

Well, as I see it, the LF will make a ruling and then the Yocto Project with have to follow.  If OE decides not to change then this put the two projects at odds.

Since we have deferred most issues regarding repos to the Maintainers of those repos, so I would say we see what the maintainers want to do.  If there is no action from the maintainers then this would be escalated to the appropriate TSC's and then the Board.  Community input is always helpful.

As a maintainer of a few layers, I plan on aligning with what the kernel does and will be in-sync with the transition plan from OE/YP.

2. Scope Creep. From the dawn of the OE project, there have been "discussions"
around variable/function names. In order to keep this work sane and concise, I
must insist that the scope of this work is "inclusive language" not "PN is too
cryptic for beginners, we should expand it to PACKAGENAME"

3. Deprecation Plan. Given the layered nature of the ecosystem, inevitably
there will be not-so-frequently-used layers out there that could stop working
entirely depending on how this work is implemented. Do we continue to support
the "old" language indefinitely? Do we have a flag day where everything
changes at once? Do we give warnings for X releases then have a cut off?
I think a switch over plan and how that is communicated is the challenge.  We can not enforce bad actors in layers today so doing what we have done in the past seems more appropriate like, warns first then error out. This then places the burden on the user of the bad layers to go get them fixed.

4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.
I think what the kernel changes its master branch name to we should follow. Regarding the other name changes, maybe aligning with terminology  changes the kernel does and what is left, maybe we define those at that time.  There is nothing we can do with recipes that pull from dead projects that use some sort of cloning. 

5. Backports. How far back do we make changes?
I would not suggest this as it  has the potential destabilize the current LTS version.  Not only that, there is product in the field already so altering older branches may introduce some instability.

6. Terminology. The Linux kernel project has put out some recommendations:

We already reference the kernel for processes so what they do, I think we just pick up unless we don't like what they did.


To start the discussion, can we please get a consensus on item #1? If
positive, can we then work on whether we agree with the list of items (have I
forgotten anything, are there things to add to the list, or things to remove
from the list)? THEN can we please focus on each of the items from the list we

I think that would be a more sane approach rather than trying to do everything
at once.

Best regards,


Join { to automatically receive all group messages.