Thanks for bringing this up and writing a summary. The OE and YP TSCs
are aware of this and are starting to have discussions about it. I have
also been looking at what other projects and the Linux Foundation are
doing. As yet there aren't any real conclusions, I've been kind of
waiting for git itself to make a decision as that could significantly
influence 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 it
potentially ends up being branded as unsupportive of certain groups at
best and racist and worse at worst.

That is not a good position to have to make decisions from, it does
feel like there is no choice in the matter and we'll have to do
something or perhaps anything and everything.

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"

Shouldn't that be RECIPENAME? ;-)

I think my reply (which was my first thought) proves your point! :)

There is a valid argument that some variable names are problematic and
we don't change them simply due to the pain involved. If we are
changing them, we should aim to get them right?

As one of the maintainers, I actually get really depressed when people
say "what kind of a person picked a name like this". Naming is much
harder than people think. I've been responsible for some of it and
don't like some of the end results we've had, equally, I struggle to
come up with better ideas for some areas.

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?

The good news is that there is a way for layers to mark what they're
compatible with and they have to opt in with each new release. As such
I suspect we could move fairly quickly and in most cases just error out
if/where old names were used?

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.

We are not responsible for other other upstreams, we will just follow
their lead. As such for example I don't think we should take patches
changing terminology in upstream software.

I think all the things you mention are things we will have to look at.
Some aren't a big issues and easy to change, the branch and variable
names are probably the most problematic.

5. Backports. How far back do we make changes?

This is where it gets potentially most worrying. For example, does the
project promote racism if it doesn't take the changes back into the
LTS? Does having the LTS and master diverge make things more or less
difficult to maintain. We might make a decision now but what will
'peer' pressure look like 1 or 2 years into the LTS?

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 the
reasons I mention above, regardless of what they might think.

My personal position (not a project one) is that I do see the issues in
the terminology and I appreciate the community's desire to want to do
something about it, I want to support that. I do however worry that its
going to cause weeks of work in dealing with the fallout from
changes and a lot of that will end up falling to me personally as few
people step up to do that kind of thing beyond the first patch.

The kind of thing I'm referring to isn't writing the patches to change
something, or coming up with a plan for that. Its writing replies like
this to discussion on the mailing list or explaining to a user on irc
that they're using docs for "pre-change" and they need the "post-
change" docs, updating the docs themselves (we don't have a docs
maintainer right now, I'm kind of doing it) or attending the bug triage
call and figuring out how to deal with issues (who takes these bugs?).

Is this a good way to spend the time? Would that time be better spent
helping some new users and getting new active maintainers involved with
the project? Difficult to say.

Assuming the answer is yes, we need to do something (I really can't see
any other way forward), some logical next steps and places to start
are:

a) Find a list of patches that need renaming and send patches to
rename them. This shouldn't be an issue.
b) Create a list of function names that need renaming. Patches to
handle those also shouldn't be too invasive.
c) Create a list of problematic variable names so we can understand
the scope of that problem. We can then formulate plans around them
on a case by case basis.

For branch naming there is potential impact on the infrastructure and
demands on Michael's time as well as mine, depending on what we might
do there. There are large chunks of code like the autobuilder codebase
which have limited numbers of contributors yet are key to the project's
health. I think its going to be the most invasive area to change, how
invasive will depend on exactly what we do, assuming we do it.

Cheers,

Richard