Thanks for bringing this up and writing a summary. The OE and YP TSCsare aware of this and are starting to have discussions about it. I havealso been looking at what other projects and the Linux Foundation aredoing. As yet there aren't any real conclusions, I've been kind ofwaiting for git itself to make a decision as that could significantlyinfluence what we do for practical reasons.On Wed, 2020-07-15 at 01:31 -0400, 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?
The challenge with this topic is that anyone arguing against itpotentially ends up being branded as unsupportive of certain groups atbest and racist and worse at worst.That is not a good position to have to make decisions from, it doesfeel like there is no choice in the matter and we'll have to dosomething or perhaps anything and everything.
In comparison to Github (hundreds of employees, sold for billions) or the Linux kernel with contributors from large commercial ecosystems (e.g. RedHat/IBM and Google/Android), OE was architected by a smaller set of volunteers and companies. With less resources, careful scheduling can reduce disruption and maximize confidence in shared decisions.
Practically: are there companies who would stop contributing to OE until names are changed? Are there consumers of OE-based equipment who would boycott said equipment until names are changed? If yes, would those companies offer funding to make their requested changes? If not, such change requests could join the backlog for de-dupe alongside related changes to core components.
If there were a negative campaign planned against OE, it would inadvertently provide OE with much-needed publicity, especially after appropriate changes could be agreed by the community in a shared decision. Rushed, pre-emptive changes in fear of such a campaign would be more effort for less impact. And no, this is not a challenge!
The context of decisions matter. At this halfway point of 2020, it feels less coherent than previous years, with unpredictable events competing for reduced financial and psychological resources, among geographies and companies. This year is also missing in-person meetings like OEDAM, for consensus-building on complex issues.
U.S. FTC mandates [1] a cooling-off period for some transactions made in temporary locations. With many people isolated from in-person social interaction, and the unfettered power of social media to propagate ideas online without substantive debate, the "temporary locations" of 2020 are not conducive to making decisions with long-lasting stability.
A cooling-off period would enable limited OE resources to be later deployed in service of a broader consensus.
5. Backports. How far back do we make changes?
This is where it gets potentially most worrying. For example, does theproject promote racism if it doesn't take the changes back into theLTS? Does having the LTS and master diverge make things more or lessdifficult to maintain. We might make a decision now but what will'peer' pressure look like 1 or 2 years into the LTS?
We could aim for the next LTS, which would be released in late 2021? The time between now and early 2021 could be used to learn from the broader OE ecosystem and reach consensus on naming-related changes, with May 2021 commit to the release that will become YP LTS in late 2021. Ideally with the benefit of an in-person OEDAM in early 2021.
6. Terminology. The Linux kernel project has put out some recommendations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb
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
create?
I think that would be a more sane approach rather than trying to do everything
at once.
I don't see that anyone can realistically argue against 1 for thereasons I mention above, regardless of what they might think.
Since monoculture is the opposite of multiculture, hopefully each community can make choices appropriate to their project, rather than replacing an accidental/historical monoculture with an external monoculture that is equally a snapshot of time and space.
OpenEmbedded's uniquely flexible layer mechanism enables granular overrides and "loose coupling" of requirements that would otherwise lead to forks. Although OE is more bazaar than cathedral, there can be periods of focus which consolidate organic patterns. How might OE evolve to be less fragile to some name changes?
While the project is incurring the cost of intrusive changes and validation for non-regression, can we use this rare opportunity to make namespace-related improvements that would otherwise be difficult to coordinate? In terms of matching donations: contrition for the past can be matched with an architectural investment in future flexibility.
Finally, for a diversion into semantics and perception of language, consider this 1960s variant of English, E-Prime, which excluded the verb "to be". It's a thought experiment about our expectations of language. The more we understand the limits of a tool, the better we can use the tool appropriately.
