[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ccbb3aeb-daa1-49ba-b729-964bd97748bc@leemhuis.info>
Date: Fri, 2 Feb 2024 09:14:55 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Kalle Valo <kvalo@...nel.org>
Cc: ath11k@...ts.infradead.org,
Linux regressions mailing list <regressions@...ts.linux.dev>,
linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [regression] ath11k broken in v6.7
On 29.01.24 12:33, Kalle Valo wrote:
> Thorsten Leemhuis <regressions@...mhuis.info> writes:
>> On 22.01.24 09:24, Kalle Valo wrote:
>>> "Linux regression tracking (Thorsten Leemhuis)"
>>> <regressions@...mhuis.info> writes:
>>
>> That "#regzbot link:" will vanish as well (at least from the docs, it
>> will remain to be supported), as people use it wrong in various
>> different ways: for duplicates, reports (like your did), patch
>> submissions fixing the issue (then 'regzbot monitor' should have been
>> used) among others. Which is totally understandable now that I look at
>> it. That's why it will be replaced by "#regzbot related: <url>" to avoid
>> any connection with the Link: tag used in commits; for duplicates
>> "#regzbot dup:" will stay around.
>
> So, in the new interface, how should I handle a situation that a
> regression is first reported on the mailing list, added to regzbot and
> later there's also a bug report opened for the issue?
You will have to options: reply to the first report with a "#regzbot
duplicate https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542"
or add a comment to the bugzilla ticket pointing to a report already
tracked by regzbot, e.g. "#regzbot duplicate
https://lore.kernel.org/not_relevant/msgid-423423423423423423/"
>>> I wish there would be a person who could follow stable
>>> releases from wireless perspective and make sure everything is ok there.
>> Maybe at some point regression tracking can help somewhat with that. But
>> I still have to fix a few things to make people use it and scale it up.
> I just feel it should be more than that, I'm worried that randomly
> taking wireless commits to stable releases is risky. There really should
> be someone looking after wireless (read: reviewing patches) in stable
> releases. This would be a good role for someone who is interested to
> learn how kernel.org development works and helping the community. Do we
> have a way to announce these kind volunteer vacancies somewhere? :)
Not that I know of. Guess kernelnewbies might be the best place for that
(and maybe they have something like that already...).
Ciao, Thorsten
Powered by blists - more mailing lists