Message-ID: <9fb128b1-d625-477f-8a16-aade00b13bc6@leemhuis.info>
Date: Thu, 25 Apr 2024 11:33:08 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 Jiri Kosina <jikos@...nel.org>, Douglas Anderson <dianders@...omium.org>,
 Hans de Goede <hdegoede@...hat.com>, linux-input@...r.kernel.org,
 linux-kernel@...r.kernel.org, Kenny Levinsen <kl@...wtf>,
 Benjamin Tissoires <benjamin.tissoires@...hat.com>,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: regression fixes sitting in subsystem git trees for a week or
 longer

On 25.04.24 10:44, Benjamin Tissoires wrote:
> On Apr 25 2024, Thorsten Leemhuis wrote:
>> On 24.04.24 20:53, Linus Torvalds wrote:
>>> On Wed, 24 Apr 2024 at 09:56, Thorsten Leemhuis
>>> <regressions@...mhuis.info> wrote:
>> [...]
>> And the arch linux wiki even documents a workaround:
>> https://wiki.archlinux.org/title/Lenovo_ThinkPad_Z16_Gen_2#Initialization_failure
>>
>> Those are just the reports and discussions I found. And you know how
>> it is: many people that struggle will never report a problem.
> 
> short FYI, (I've Cc-ed you on the PR), but I just sent the PR for HID,
> which includes this fix.

Great, many thx. Saw it right after sending my mail... :-/

>> Is cherry picking from -next as easy for you? Maintainers sometimes
>> improve small details when merging a fix, so it might be better to
>> take fixes from there instead of pulling them from lore.
> 
> Maybe one suggestion that might help to reduce these kind of situations
> in the future: can you configure your bot to notify the maintainers
> after a couple of days that the patch has been merged that it would be
> nice if they could send the PR to Linus?

Yes, that is an idea in the long run, but I'm not sure if it's wise now
or later. People easily get annoyed by these mails (which I totally
understand!) and then will start hating the bot or regression tracking
in general. That's why I'm really careful here.

There are also the subsystems that regularly flush their fixes shortly
before a new -rc, so they likely never want to see such reminders. And
sending them right after a new -rc is better than nothing, but not ideal
either.

IOW: it's complicated. :-/

> In this case I bet Jiri forgot to send it because he was overloaded and
> so was I.

Understood and no worries. But this became a good opportunity to raise
the general problem, as that is something that bugs me. Sorry. Hope you
don't mind to much that I used that chance.

> So a friendly reminder could make things go faster.

I'll already did this occasionally manually, but that of course does not
scale. Sometimes I wonder if it would be more efficient for nearly all
of us if subsystems just flushed their -fixes branch shortly before each
new -rc, as Linus apparently is not bothered by PRs that contain just a
change or two. But that of course creates work for each of the subsystem
maintainers, unless they creates scripts to handle that work nearly for
free (it seems to me the x86 folks have something like that).

Of course that would mean...

> And maybe, before sending the reminder, if you could also check that the
> target branch hasn't been touched in 2 days that would prevent annoyances
> when we just added a commit and want to let it stay in for-next for 24h
> before sending the full branch.

..that nothing big or slightly dangerous should be merged to -fixes
branches on Fridays.

>> P.S: Wondering if I should team up with the kernel package maintainers
>> of Arch Linux, Fedora, and openSUSE and start a git tree based on the
>> latest stable tree with additional fixes and reverts for regressions
>> not yet fixed upstream...[1] But that feels kinda wrong: it IMHO
>> would be better to resolve those problems quickly in the proper
>> upstream trees.
> 
> I would also say that this is wrong. Unless all regressions go through
> your tree and you then send PR to Linus, [...]

Ohh, sorry, I was not clear here, as that would be totally wrong --
fixes definitely should go through the subsystems trees, as they have
the knowledge and the infra to check them (hmm, maybe a dedicated tree
might make sense for the smaller subsystems, but let's ignore that).

What I meant was just a tree those distros could merge into their
kernels to quickly resolve issues that upstream is slow to fix. But that
obviously has downsides, too. And is yet more work.

> However, do you have some kind of dashboard that you could share with
> the package maintainers? This way they could easily compare the not-yet
> applied fixes with their bugs and decide to backport them themselves.

I have for the kernel overall, but nothing subsystem specific. But that
is pretty high on my todo list, as...

> In other words: let others do the hard work, you are doing a lot already

..I'm very well aware of this. :-/

Ciao, Thorsten

Powered by blists - more mailing lists