On Thu, 2021-09-09 at 20:43 -0700, akuster808 wrote:

On 9/9/21 9:09 AM, Richard Purdie wrote:

Hi All,

We have a decision facing us with 3.5. There are a number of invasive issues
looming on the horizon and I'm not sure exactly what the best thing to do with
them is.

a) Inclusive language

A lot of variables potentially need renaming with varying options for backwards
compatibility. Do we add compatibility for all cases.

By backward compatibility do you mean allowing a layer to use one of the
offending variables? if so, what is the point?

At the very least we probably have to detect usage of old variables. There is an
argument that compatibility could be retained for some of them for a transition
period and previously there has been a lot of requests for a longer
deprecation/transition period so it is unclear if users would accept/want
another flag day.

How much do we help users with migration?

You mean like in a script?

Yes.

Is there wide support for the changes?

You mean this LF project? https://inclusivenaming.org ( Think its overly
complication things)

or OE/YP folks getting involved?

I mean would the OE/YP people want to do the work involved, both in planning it
for the core and then doing the work in updating their own layers.

Do we change the master branch to something else? I personally have a
preference
for "devel" over "main" regardless of what others are doing as it matches
what
it is in our case. Changing that alone is days of work for me trying to get
all
our automation to deal with it.

If the master branch gets renamed, what about yocto-buildhistory,
yocto-buildstats and yocto-testresults? Would master branches or tags
get renamed as well? Is this part of the day's worth of work you mentioned?

Would the Yocto Project enforce a renaming in all the repos they host?

What about layer-index?

All good questions. The days of work I was mentioning would cover some of this
but there is a lot to do, more than people realise.

I remembered what I was missing too:

j) Convert to SPDX license names

We should really switch to using SPDX license names in the LICENSE field
directly and be able to drop the current SPDX mapping code.

Cheers,

Richard