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. How much do we help users with migration? Is there wide support for the changes? 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. 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 (#1307): https://lists.openembedded.org/g/openembedded-architecture/message/1307 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]] -=-=-=-=-=-=-=-=-=-=-=-
