Re: inclusive language
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 YoctoTo 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 git.oe.org and YP one for git.yp.org.
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 MaintainersFor 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 theTo 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 shouldI 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.
For some things we did look at what the kernel did and did something6. Terminology. The Linux kernel project has put out someWe already reference the kernel for processes so what they do, I
different for very good reasons. Its a data point but I think its only