From: Philip Li <philip.li@intel.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Richard Weinberger <richard@nod.at>,
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, 7 Jun 2023 17:39:39 +0800 [thread overview]
Message-ID: <ZIBQWytL3zhWFLgd@rli9-mobl> (raw)
In-Reply-To: <a953b19efca20b470759b1d53beb957a11062ba1.camel@sipsolutions.net>
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@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
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
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2023-06-07 9:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 18:24 [PATCH v2] uml: Replace strlcpy with strscpy Azeem Shaikh
2023-06-06 20:51 ` Richard Weinberger
2023-06-06 21:08 ` Azeem Shaikh
2023-06-07 4:23 ` Eric Biggers
2023-06-07 8:28 ` Reported-by/Closes tag for uncommitted issues (was: Re: [PATCH v2] uml: Replace strlcpy with strscpy) Johannes Berg
2023-06-07 8:34 ` Richard Weinberger
2023-06-07 9:10 ` Philip Li
2023-06-07 9:17 ` Johannes Berg
2023-06-07 9:39 ` Philip Li [this message]
2023-06-07 9:43 ` Johannes Berg
2023-06-07 9:47 ` Philip Li
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=ZIBQWytL3zhWFLgd@rli9-mobl \
--to=philip.li@intel.com \
--cc=Jason@zx2c4.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=azeemshaikh38@gmail.com \
--cc=ebiggers@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=lkp@intel.com \
--cc=maxk@qti.qualcomm.com \
--cc=richard@nod.at \
/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).