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? > How much do we help users > with migration? You mean like in a script? > 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? > > 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? - armin > > I am frustrated that after lots of people saying this was important and the > TSC > putting a process/plan in place, the work hasn't been done. This does imply > that > if "we" do it, I'll get to do a lot of work on it which I have mixed feelings > about. Not doing it also looks bad for the project though. > > b) layer.conf changes > > Part of the reason the LAYER* variables didn't change in the overrides changes > is that not only are they not overrides in any way they're used but also that > we > could probably do with dropping a lot of the legacy ways layers work and adopt > something easier for people to understand (e.g. the term collections is old > and > we have too many ways of handling priorities). > > I think a deeper cleanup of layer configuration is possible and desirable but > it > would mean dropping "features" some people are using. I don't know how much > support there would be for that. Would people accept a standard layer priority > for example? > > c) data store operational changes > > One of the things the new overrides changes lets us do is know definitively > what > is a variable and what is an override. Currently when you call d.keys(), you'd > get A and A:qemux86. We could decide that only A should be shown and this > could > speed up certain operations due to the simplified key list. > > d) potential syntax removal > > Another option from the overides changes would be to disallow certain operator > combinations. One often commented on example would be A:append:b += "c", there > are others depending on how far we wanted to go with that. These should be > possible to at least show errors to the user. > > e) potential data store internals rewrite > > Yet another possible move from the overrides syntax change is that it would > allow us to remove the "overridedata" element of the data store into the > specific variables. I have a proof of concept of this but it turns out to be > really ugly code, unless we accept some user visible changes to the behaviour > of > the datastore (and/or remove some forms of syntax). At present I'm > experimenting > without making user visible changes but we do have potential decisions to make > here too. > > f) f-strings in python code > > We now have a compatible python version but I'm reluctant to start changing > large chunks of the code base with the risks of breaking in transitions. The > more of this we take in, the bigger the risks of something being backported to > older releases which causes issues. > > FWIW, I'm seeing signs other layers are going to start using this regardless > of > what the architecture list or TSCs say. I really don't want to get into a > position where we have multiple "standards" for things as the current > situation > is bad enough. I'm therefore worried about this one a lot. Part of me wonders > if > we should just start allowing them and watch things unravel for older > releases. > > g) bitbake internal changes > > Other things in bitbake are showing their age. The client/server model it uses > really needs reworking to use async apis. tinfoil needs to adapt to handle > parallel parsing if it is to scale in the future. The logging in bitbake > needs a > total overhaul and previous work completing, with potential user visible > changes. > > h) merge of some currently optional functionality into the core > > Merging bits of reproducible builds and maybe some license/sbom handling into > the core project workflows as not optional may be desirable to reduce the test > matrix and the chances of people not testing codepaths with changes. > > i) dropping/cleaning up some core code > > Chunks of the license class code come to mind, there are probably other areas > which could do with cleanup. > > > There are probably more of these, these are just the handful of issues that > came > to mind right now. I can't help think there were some others that were > discussed > in the tech call on Tuesday. > > I'm conscious we don't want to do what python did with the 2->3 transition. > Equally, I know there are a lot of things we could do with changing, not a lot > of people interested in doing the work and an LTS "looming" which we may or > may > not want to get some of these changes into. > > Thoughts on how much we should be considering for 3.5 and the changes in > general > welcome... > > Cheers, > > Richard > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1308): https://lists.openembedded.org/g/openembedded-architecture/message/1308 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]] -=-=-=-=-=-=-=-=-=-=-=-
