Hi Otavio, On Fri, 2026-03-27 at 19:38 -0300, Otavio Salvador via lists.openembedded.org wrote: > Em sex., 27 de mar. de 2026 às 14:09, Richard Purdie via > lists.openembedded.org > <[email protected]> escreveu: > > > > On Thu, 2026-03-26 at 13:35 -0500, Randolph Sapp wrote: > > > On Mon Mar 16, 2026 at 12:25 PM CDT, Randolph Sapp via > > > lists.openembedded.org wrote: > > > > On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via > > > > lists.openembedded.org wrote: > > > > > From: Randolph Sapp <[email protected]> > > > > > > > > > > No functional changes. Just bumping PR to help with automated > > > > > > > > Hey Paul, have you gotten a chance to review this series yet? I've been > > > > told you may have some comments. > > > > > > > > Randolph > > > > > > Has anyone gotten a chance to review this yet? > > > > Paul and Ross have some thoughts but we're basically still drowning in > > the backlog of patch review. We're all frustrated about that. This one > > is more Ross' area of expertise than mine so I'm waiting on that.I'm > > replying since I do feel bad we've not got to this yet. > > > > I wish it were different, I'm doing what I can with various patches but > > I'm also behind on review for several. > > > > The challenge with this patchset is it is a fairly invasive change, it > > does inject a go dependency into a core part of our graphics stack and > > as such, I think we're all quite nervous about it. It has taken a lot > > of back and forth to pass the autobuilder's tests and that in itself is > > a bit of a worry. > > I understand the concern — this is an invasive change and caution is > warranted for something that touches such a core part of the graphics > stack. > > That said, I think it's worth recognizing that Randolph has been > exceptionally persistent and responsive throughout this process. We're > at v16 now, and every issue that has come up — from cgo > reproducibility to busybox-init support to autobuilder failures — has > been addressed. That level of commitment to getting it right speaks > well for the long-term maintainability of this work.
I realise and fully recognise Randoplh has been really patient and persistent, yes. I can only apologise for the length of time this is taking, I do feel really bad about it. I've been talking about one of the issues here in meetings recently, specifically that patches passing on the autobuilder doesn't mean the patches are "right", just that they don't regress our automated tests. I think we need to make it clearer that we put patches in for testing in parallel with other review on the basis it is easier in some ways and can highlight issues. It doesn't negate the other half of the process. In this case, the patches had a lot of issues there and it took a while so there weren't regressions. You mention the cgo reproducibility issue, I want to be mention there are a number of other complaints in my inbox about the changes made there, how there are regressions elsewhere caused by those changes. I can't really ask anyone else to try and handle that so that just falls to me, but it does reduce my bandwidth elsewhere. Unfortunately the people who need to review and sign off on this have a number of other things in their queues. People only have finite time and I can't force them to do things. I'd also note that I did ask many times in the weekly calls and other project meetings about what should block this release and this patchset was not raised. That isn't to say it isn't important but there are other pressing issues competing with it. > Regarding the Go dependency: Go support in OE-Core has a long history > at this point and is well-maintained. I don't think introducing it as > a dependency in the graphics stack is as risky as it might seem at > first glance — we're not pulling in something experimental. > > The problems this series solves are real. The race conditions with > weston-init and DRM device registration, the scripting sprawl around > xserver-nodm-init — these are pain points that affect downstream > users. emptty offers a clean, unified solution for both X11 and > Wayland sessions. Whilst it does solve a real world problem, that doesn't mean it should go in without the right level of review and wider community buy-in. We don't have that yet. There is also significant risk to changing a key runtime component like that this close to release. Build components aren't so bad as we have better testing, runtime is hard. The rpm 6 patchset is in a similar position - too risky for the release now. > In my opinion, this patchset should go in. Noted, thanks. I appreciate the review of it. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#234141): https://lists.openembedded.org/g/openembedded-core/message/234141 Mute This Topic: https://lists.openembedded.org/mt/118035107/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
