Re: [PATCH 2/4] xen/scripts: add cppcheck tool to the xen-analysis.py script

From: Jan Beulich <jbeulich@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Luca Fancellu <Luca.Fancellu@arm.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Wei Chen <Wei.Chen@arm.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH 2/4] xen/scripts: add cppcheck tool to the xen-analysis.py script
Date: Thu, 1 Dec 2022 09:33:45 +0100	[thread overview]
Message-ID: <471b6470-b0b7-a97d-2114-a1871e237a89@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2211301145132.4039@ubuntu-linux-20-04-desktop>

On 30.11.2022 21:26, Stefano Stabellini wrote:
> On Wed, 30 Nov 2022, Luca Fancellu wrote:
>>> I think the revert of the cppcheck integration in xen/Makefile and
>>> xen/tools/merge_cppcheck_reports.py could be a separate patch. There is
>>> no need to make sure cppcheck support in the xen Makefile is
>>> "bisectable". That patch could have my acked-by already.
>>
>> Ok I will split these changes in a following patch
>>
>>>
>>> Also the document changes introduced in this patch have my reviewed-by:
>>> - docs/misra/cppcheck.txt
>>> - docs/misra/documenting-violations.rst
>>> - docs/misra/false-positive-cppcheck.json
>>> - docs/misra/xen-static-analysis.rst
>>
>> Thank you, should I put those files in a separate patch with your rev-by before
>> this patch or this is just a comment for you to remember which file you already
>> reviewed?
> 
> If Jan and the other reviewers are OK, I think you could split them out
> in a separate patch and add my reviewed-by. If Jan prefers to keep it
> all together in one patch, then I wrote it down so that I remember what
> I have already acked :-)

Docs changes being split off and going in first is okay as long as what
is being documented is present behavior. If other changes are needed to
make (parts of) new documentation actually correct, then it should imo
go together. If new documentation describes future behavior (e.g.
design docs), then of course it's fine as well to go in early, as then
there simply is no code anywhere which this would (temporarily) not
describe correctly.

Jan