Re: inclusive language

Richard Purdie

On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:
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.
To be really clear, whilst you keep saying this, I have heard of no
such plans from the LF and I have asked. Yes, the LF is a strong
believer in diversity and does take these issues seriously but as I
understand it, it is for the individual LF projects to find their way
in this as there is no "one size fits all" solution. I expect there
will be some guidance but the decisions rest with the TSCs, the OE one
for and YP one for

What may also be a bigger issue is member companies placing
requirements on the project.

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.
For layers not on project infrastructure, yes. For repos hosted on our
infrastructure I suspect the TSCs will aim for consistency. We do
mirror a number of repos which may be harder.

I would like OE and YP to align on whatever we decide to do and whilst
I can't say for sure they will, my voice on the TSCs will certainly be
aiming for that.

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.
To be honest I'm not so interested what the kernel does. I'm more
interested in what git (as the tooling we rely upon) does.

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.
I think variable naming is for us to determine as appropriate. The
kernel's plans on branch names are one data point, I think git itself
is the most relevant.

6. Terminology. The Linux kernel project has put out some
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.
For some things we did look at what the kernel did and did something
different for very good reasons. Its a data point but I think its only



Join { to automatically receive all group messages.