Message-ID: <ZIBQWytL3zhWFLgd@rli9-mobl>
Date:   Wed, 7 Jun 2023 17:39:39 +0800
From:   Philip Li <philip.li@...el.com>
To:     Johannes Berg <johannes@...solutions.net>
CC:     Richard Weinberger <richard@....at>,
        Eric Biggers <ebiggers@...nel.org>,
        Azeem Shaikh <azeemshaikh38@...il.com>,
        Maxim Krasnyansky <maxk@....qualcomm.com>,
        anton ivanov <anton.ivanov@...bridgegreys.com>,
        linux-hardening <linux-hardening@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-um <linux-um@...ts.infradead.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        kernel test robot <lkp@...el.com>
Subject: Re: Reported-by/Closes tag for uncommitted issues (was: Re: [PATCH
 v2] uml: Replace strlcpy with strscpy)

On Wed, Jun 07, 2023 at 11:17:54AM +0200, Johannes Berg wrote:
> On Wed, 2023-06-07 at 17:10 +0800, Philip Li wrote:
> > > > So it seems we should ask the robot maintainers to just stop suggesting
> > > > those tags?
> > > 
> > > Agreed.
> > 
> > Thanks all for the feedback. We will carefully consider how to present the
> > suggestion clearly.
> > 
> > For now, because the bot covers both upstream and developer repos, there
> > can be various situations, such as the bug is found in upstream. 
> 
> Ah yes, that was actually in my mind, but I forgot to write about it,
> sorry.
> 
> I agree completely, in case that you find a bug in an already committed
> tree, and there will be a separate commit to fix it, it's completely
> reasonable and useful to have those tags.
> 
> > So the bot
> > tries to let author decide how to apply the tags in appropriate way that
> > they feel comfortable.
> 
> Right. It just seems that many authors aren't really all that familiar
> with the processes yet, and take the suggestion at face value.
> 
> > In the report, we now uses phrases like below
> > 
> > 	If you fix the issue, kindly add following tag where applicable
> > 	| Reported-by: kernel test robot <lkp@...el.com>
> > 	| Closes: https://lore.kernel.org/oe-kbuild-all/202305311135.zGMT1gYR-lkp@intel.com/
> > 
> > But this may be not clear enough or not the best way to suggest. We will
> > consider whether we can detect some situations (like RFC patch) which is
> > no need for such tags to avoid confusion.
> > 
> 
> Right. Maybe the only thing really needed would be to say something like

Thanks a lot, the suggestion really helps us to get this better.

> 
> "If you fix the issue in a separate patch/commit (i.e. not just a new
> version of the same patch/commit), kindly add ..."

Is that ok we just take this phrase as a quick improvement for first step, which
is

"If you fix the issue in a separate patch/commit (i.e. not just a new
version of the same patch/commit), kindly add following tags:"

This could help remind for most cases if not all. Also this allows us
not doing "complex" judgement by the bot itself.

> 
> or even just
> 
> "If you fix the issue in a separate commit, kindly add ..."
> 
> so it's clear that if you're changing the commit, it's not really
> something that should be done? In which case probably even a Fixes tag
> should be there, but I wouldn't want to recommend adding that since the
> commits may still change etc.
> 
> I don't know all the processes behind it, but I'm thinking that even if
> the bot picked up a patch from the list, it could get committed before
> and then fixed in a separate commit.

You are right, thanks for reminding this. The bot monitors both patches
in the mailing list and repos of developers. It could happen that a patch
exists in both place, though there's logic to avoid testing both but can't
promise which side got tested first.

> 
> johannes

Powered by blists - more mailing lists