Re: Maintaining ABI Compatibility for LTS branch

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2022-02-09 at 14:13 -0500, Sinan Kaya wrote:
> 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.

I agree, this either needs input from the community in order to drive it or a
sponsor. It will be interesting to see if people are interested in doing this
and I guess we can gauge that from the replies to this thread to see if people
do want to do it. I can tell you first hand how badly the existing maintainers
are burning out with the current load so we need new people.

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

We both agree on incremental improvements and I am fine with that. I don't want
any patch acceptance taken as a sign we're goging to add a significant process
burden though. I'd prefer we have a broad agreement of what the end objective is
architecture wise too.

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

"None of them got merged" isn't particularly fair here. There was a brief thread
on the yocto list, no patches were proposed or reviewed and the implementation
is a standalone layer so doesn't need to merge anyway, people could use it
already if they wanted.

If the question is whether something would be accepted into core, the answer is
possibly, it would depends. The quality of the code in that layer needs
improving for core and I'm not sure about the approach. Hooking it against
buildhistory is "easy" but as I mentioned in separate discussions earlier today,
buildhistory is getting pulled in different directions (such as a SBOM) and I'm
worried about some of the extensions to it. Certainly, the ABI saving shouldn't
really be buried in a do_install postfunc and perhaps is more of a build history
item that some others that are being proposed.

This probably does need a discussion on the architecture list and we need some
discussion and decisions about where/what buildhistory could/should do. Adding
this to buildhistory is all well and good but we don't have a meaningful
integration/monitoring of existing buildhistory issues in our
autobuilder/workflow today even before adding new things.

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

Ok.

Cheers,

Richard