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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56139): https://lists.yoctoproject.org/g/yocto/message/56139 Mute This Topic: https://lists.yoctoproject.org/mt/89009568/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
