Linux EDAC development
 help / color / mirror / Atom feed
From: Zhiquan Li <zhiquan1.li@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"naoya.horiguchi@nec.com" <naoya.horiguchi@nec.com>
Subject: Re: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the capture kernel panic
Date: Tue, 17 Oct 2023 09:39:36 +0800	[thread overview]
Message-ID: <916aa2dc-ea1e-4f23-a958-fa36dfb66af9@intel.com> (raw)
In-Reply-To: <20231014101850.GAZSprCtc6QYEiGedU@fat_crate.local>

On 2023/10/14 18:18, Borislav Petkov wrote:
> You should slow down and take the time to read the document I pointed
> you at.

I'd like to revise the tag list as below for next version, and reference
rules are following each action.  Please correct me if I still
understand the rules in submitting-patches.rst wrongly.

	Co-developed-by: Youquan Song <youquan.song@intel.com>
	Signed-off-by: Youquan Song <youquan.song@intel.com>
	Signed-off-by: Zhiquan Li <zhiquan1.li@intel.com>
	Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
	Cc: Borislav Petkov <bp@alien8.de>


1) As the author of the initial patch and the person who submitting the
patch, I put my SoB following Youquan's tags per below rule:

	Notably, the last Signed-off-by: must always be that of the
	developer submitting the patch.


2) Remove Tony's SoB.  I had confirmed with him, he needn't
Co-developed-by: tag, so the SoB added by himself in V1 and V2 should be
removed.
In fact, I'm not sure how to deal with such SoB for "RESEND" case.
While resent V2 I retained the SoB to reflect the chain.  According to
my understanding, the RESEND process emphasizes "not modifying".


3) Remove Ingo's SoB.  Because a new version means a new review cycle,
the SoB added in V2 should be reset to reflect the *new* real route,
unless Ingo needs a Co-developed-by: tag. Relative rule is following:

	Any further SoBs (Signed-off-by:'s) following the author's SoB
	are from people handling and transporting the patch, but were
	not involved in its development. SoB chains should reflect the
	*real* route a patch took as it was propagated to the
	maintainers and ultimately to Linus, with the first SoB entry
	signalling primary authorship of a single author.

I missed this point while I sent V3 :-(


4) Keep Naoya's Reviewed-by: according to below rule, because there is
no substantial change in V3.

	Both Tested-by and Reviewed-by tags, once received on mailing
	list from tester or reviewer, should be added by author to the
	applicable patches when sending next versions. However if the
	patch has changed substantially in following version, these tags
	might not be applicable anymore and thus should be removed.


5) Add Cc: tag to you per below rule :-)

	This is the only tag which might be added without an explicit
	action by the person it names - but it should indicate that this
	person was copied on the patch. This tag documents that
	potentially interested parties have been included in the
	discussion.

Best Regards,
Zhiquan

  reply	other threads:[~2023-10-17  1:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-14  5:17 [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the capture kernel panic Zhiquan Li
2023-10-14  5:12 ` Luck, Tony
2023-10-14  9:34   ` Zhiquan Li
2023-10-14 10:18     ` Borislav Petkov
2023-10-17  1:39       ` Zhiquan Li [this message]
2023-10-16  9:11     ` Borislav Petkov
2023-10-17  1:05       ` Zhiquan Li
2023-10-17  1:24         ` Luck, Tony
2023-10-17 11:18           ` Borislav Petkov
2023-10-17 15:00             ` Zhiquan Li
2023-10-17 17:35               ` Luck, Tony

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=916aa2dc-ea1e-4f23-a958-fa36dfb66af9@intel.com \
    --to=zhiquan1.li@intel.com \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=patches@lists.linux.dev \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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