linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Linux regression tracking (Thorsten Leemhuis)" <regressions@leemhuis.info>
To: Benjamin Tissoires <bentiss@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jiri Kosina <jikos@kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kenny Levinsen <kl@kl.wtf>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Linux regressions mailing list <regressions@lists.linux.dev>
Subject: Re: regression fixes sitting in subsystem git trees for a week or longer
Date: Thu, 25 Apr 2024 11:33:08 +0200	[thread overview]
Message-ID: <9fb128b1-d625-477f-8a16-aade00b13bc6@leemhuis.info> (raw)
In-Reply-To: <qcd5klmhyx23rowpbm4egshm6hemhh4stq7r6soblnuul55524@yyktdlowepw7>

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

      reply	other threads:[~2024-04-25  9:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-31 18:24 [PATCH v2] HID: i2c-hid: Revert to await reset ACK before reading report descriptor Kenny Levinsen
2024-04-02 11:06 ` Hans de Goede
2024-04-02 11:30   ` Kenny Levinsen
2024-04-02 11:43     ` Hans de Goede
2024-04-22 17:10 ` Linux regression tracking (Thorsten Leemhuis)
2024-04-23 14:59   ` Benjamin Tissoires
2024-04-24 16:56     ` regression fixes sitting in subsystem git trees for a week or longer (was: Re: [PATCH v2] HID: i2c-hid: Revert to await reset ACK before reading report descriptor) Thorsten Leemhuis
2024-04-24 18:53       ` Linus Torvalds
2024-04-25  8:25         ` regression fixes sitting in subsystem git trees for a week or longer Thorsten Leemhuis
2024-04-25  8:44           ` Benjamin Tissoires
2024-04-25  9:33             ` Linux regression tracking (Thorsten Leemhuis) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9fb128b1-d625-477f-8a16-aade00b13bc6@leemhuis.info \
    --to=regressions@leemhuis.info \
    --cc=benjamin.tissoires@redhat.com \
    --cc=bentiss@kernel.org \
    --cc=dianders@chromium.org \
    --cc=hdegoede@redhat.com \
    --cc=jikos@kernel.org \
    --cc=kl@kl.wtf \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).