Re: Maintaining ABI Compatibility for LTS branch

[Sinan Kaya <okaya@kernel.org>]

On 2/9/2022 1:41 PM, Richard Purdie wrote:
>>> 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.
> 

That's true, this will require engagement from the community. Tool could
take few iterations to perfect. Until then, I expect tool owner to be
responsible for fixing these bugs. Once stability is reached, it becomes
community maintained.

If the tool owner doesn't maintain and community has no interest, tool
dies and gets reverted. It is as simple as any open source engagement.

When stability is established, each code contributor to LTS would be
subject to addressing issues found before they get merged.

> 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.

It depends on your taste. I believe in smaller improvements
as opposed to throwing a big project to you that no-one will use it.

Everyone has different needs. We need to find the common ones.
That's why, I'm asking if there is an existing tool that works for
large part of the community accepting that there will be some folks
that won't have their needs addressed.

I'm interested in revisiting the tooling discussion and have these gaps
addressed for the biggest audience so that we can have something to
build upon.

> 
> 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.
> 

Noted. Hopefully, things will be not that volatile for the LTS branch
and tool would actually help the maintainer.

In an ideal world, change needs to be stopped before that happens and
have the patch author address it similar to how you monitor build
pipelines.

>> 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?
> 

https://lists.yoctoproject.org/g/yocto/topic/85279259?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,160,85279259

This was an intern project from last summer that we are interested
in expanding coverage.

> 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.
> 

OK, I didn't know the story behind the change.

>> 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:(.
> 

Got it.

>> 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.

Sure, let's find out what everyone is doing.