From: Thorsten Leemhuis <email@example.com>
To: Philip Li <firstname.lastname@example.org>
Cc: kernel test robot <email@example.com>,
Kai Huang <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
Subject: Re: [LKP] Re: [KVM] c3e0c8c2e8: leaking-addresses.proc..data..ro_after_init.
Date: Sat, 3 Sep 2022 12:27:19 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 02.09.22 14:26, Philip Li wrote:
> On Fri, Sep 02, 2022 at 12:54:05PM +0200, Thorsten Leemhuis wrote:
>> On 01.09.22 15:24, Philip Li wrote:
>>> On Thu, Sep 01, 2022 at 02:12:39PM +0200, Thorsten Leemhuis wrote:
> Thanks for the encouragement :-) The flow/process is very helpful. We will follow
> up a few things before we resuming the tracking
>>> Usuaally, we also ping/discuss with developer when an issue enters
>>> mainline if there's no response. This is one reason we tries to connect
>>> with regzbot to track the issue on mainline, but we missed the point that
>>> you mention below (it need look important).
>> I just want to prevent the list of tracked regressions becoming too long
>> (and thus obscure) due to many issues that are not worth tracking, as I
>> fear people will then start to ignore regzbot and its reports. :-/
> got it, we will be very careful to selectly tracking. Maybe we don't need
> track the issue if it is responsed by developer quickly and can be solved
Maybe, but that will always bear the risk that something gets in the way
(say a big problem is found in the proposed fix) and the regression in
the end gets forgotten and remains unfixed -- which my tracking tries to
prevent. Hence I'd say doing it the other way around (adding all
regressions reported by the 0-day folks to regzbot and remove reports
after a week or two if it's apparently something that can be ignored)
would be the better approach.
> But only track the one that is valuable, while it need more discussion, extra
> testing, investigation and so one, that such problem can't be straight forward
> to solve in short time. For such case, the tracking helps us to get back to this
> even when there's a pause, like developer is blocked by testing or need switch
> to other effort. This is just my thinking.
Yeah, the problem is just: it's easy to forget the regression to the
>> Are you or someone from the 0day team an LPC? Then we could discuss this
>> in person there.
> We will join 2 MC (Rust, Testing) but all virtually, thus not able to discuss in
> person :-(
Okay, was worth asking. :-D
> But we are glad to join any further discussion or follow the suggested
> rule if you have some discussion with other CI and reporters.
Yeah, I'm pretty sure we'll find a way to make everybody happy.
next prev parent reply other threads:[~2022-09-03 10:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 14:34 [KVM] c3e0c8c2e8: leaking-addresses.proc..data..ro_after_init kernel test robot
2022-09-01 12:12 ` Thorsten Leemhuis
2022-09-01 13:24 ` [LKP] " Philip Li
2022-09-02 10:54 ` Thorsten Leemhuis
2022-09-02 12:26 ` Philip Li
2022-09-03 10:27 ` Thorsten Leemhuis [this message]
2022-09-05 2:38 ` Philip Li
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).