On Wed, 2022-02-09 at 13:15 -0500, Sinan Kaya wrote:

On 2/9/2022 11:42 AM, Richard Purdie wrote:

There are two reasons people are interested:

a) for release stability as you mention
b) for performance as it could be tied into the hash equivalence mechanism for
artefact reuse - if A hasn't changed ABI, B dependning on it needn't rebuild.

There was a proof of concept of b) here:
https://lists.yoctoproject.org/g/yocto/message/52650

There are lots of levels it could be implemented at but it is something someone
would need to pick up and drive forward with a long term view to helping with
issues etc.

What would be the minimum acceptable solution with the least investment?
in other words, do we have a list of requirements?

You're after our LTS to maintain ABI. In order to do that we need help, not just
with patches generating some output, but in day to day running of the project,
i.e. help comparing output before and after changes. Whenever a patch is
submitted which breaks this, it will need attention and help some someone to
explain to that submitter what the issue, why it is important and hints on how
to fix it.

The idea of "least investment" sends shivers down my spine since it sounds like
you want to do the absolute bare minimum to have this happen, rather than a more
community oriented approach.

Anyway, my point is there is more to this than just a patch. We have various
kinds of build output already and reports on test regressions - nobody helps
with them. I need some kind of a sign that ABI would be different and there are
people able to help with review on an ongoing basis, else it will just be
something else I and a small number of others become overloaded with.

Our team has posted a solution. BMW folks posted a solution.
None of them got merged.

Can you remind me of your team's please?

The BMW one is about hash equivalence so wouldn't help your ABI output problem
with the LTS. From what I remember, it predates hash equivalence and the project
needed a generic equivalance mechanism complete with server done at the runqueue
level in bitbake. This has now happened so we could revisit the idea of what is
in that layer but translating it to a hash equivalence plugin.

I'd also add that even with hash equivalence done well like we ended up with, we
have only two people interested/able to work on bugs with it, the author and
myself. For a key component of the system, this worries me a lot. Adding more
complexity without maintainer support isn't going to help anyone.

Could we take the version from BMW folks, merge and have the next person
add new features where it doesn't satisfy requirements?

See above on the BMW version. I'm a little worried you're suggesting merging
something which doesn't actually do what you need/want :(.

or vice versa? or as Ross said some other work?
or none of the solutions are acceptable?

I have to admit I can't remember what the conclusion was on your team's version
but if you remind me of the patches I can try and remember. This is a bigger
problem than just patches though sadly.

Cheers,

Richard