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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1309): https://lists.openembedded.org/g/openembedded-architecture/message/1309 Mute This Topic: https://lists.openembedded.org/mt/85488159/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
