Disruptive changes and the next LTS 3.5 - what to aim for?


Richard Purdie
 

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

Join openembedded-architecture@lists.openembedded.org to automatically receive all group messages.