Re: Reported-by/Closes tag for uncommitted issues (was: Re: [PATCH v2] uml: Replace strlcpy with strscpy)

From: Johannes Berg <johannes@sipsolutions.net>
To: Philip Li <philip.li@intel.com>, Richard Weinberger <richard@nod.at>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Azeem Shaikh <azeemshaikh38@gmail.com>,
	 Maxim Krasnyansky <maxk@qti.qualcomm.com>,
	anton ivanov <anton.ivanov@cambridgegreys.com>,
	linux-hardening <linux-hardening@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	 linux-um <linux-um@lists.infradead.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: Reported-by/Closes tag for uncommitted issues (was: Re: [PATCH v2] uml: Replace strlcpy with strscpy)
Date: Wed, 07 Jun 2023 11:17:54 +0200	[thread overview]
Message-ID: <a953b19efca20b470759b1d53beb957a11062ba1.camel@sipsolutions.net> (raw)
In-Reply-To: <ZIBJadzmheKWCErq@rli9-mobl>

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

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

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.

johannes

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um