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 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 that. Cheers, Richard |
|