From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: Laszlo Ersek <lersek@redhat.com>,
Sean Brogan <spbrogan@outlook.com>,
devel@edk2.groups.io
Cc: "James Bottomley" <jejb@linux.ibm.com>,
"Jordan Justen" <jordan.l.justen@intel.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Leif Lindholm (Nuvia address)" <leif@nuviainc.com>
Subject: Re: [edk2-devel] [PATCH 1/2] OvmfPkg: start using the ECC plugin exception list
Date: Fri, 4 Dec 2020 17:05:54 +0100 [thread overview]
Message-ID: <6989494d-4dca-6a92-d748-9c413206e781@arm.com> (raw)
In-Reply-To: <7c57b6dc-de1a-8f2b-9b40-c1faf9b46bfe@redhat.com>
On 12/4/20 4:36 PM, Laszlo Ersek wrote:
> Hi Sean,
>
> On 12/04/20 16:22, Laszlo Ersek wrote:
>> On 12/04/20 05:05, Sean Brogan wrote:
>
>>> 3. Running CI locally should not be "somewhat risky". More work needs
>>> to be done to identify the root cause of the above behavior but my guess
>>> is that it has to do with EccCheck and nothing to do with
>>> pytool-extensions.
>>
>> Sorry, I guess I mixed up my references a little bit. I consider running
>> binaries downloaded from the internet risky (except from the official
>> repos of my Linux distro(s)). But that's indeed a different topic and I
>> shouldn't have generalized. Sorry about that.
>
> If you have a suggestion to improve the wording here, I'd like to hear
> that. I'd really like to go ahead with this patch set in one way or
> another, as it's blocking James's work from being merged. I don't want
> to merge a commit message here that you find offensive or just plain
> wrong though, so please suggest an improvement.
>
> Ard, do you have any comments please?
>
I appreciate your tendency to document things profusely, but in this
case, I think it is sufficient to simply mention that ECC is overly
strict, and that it should not be left up to 'the machine' to decide
whether an exception can be made. We are all bandwidth constrained, and
reviewing is enough of an effort as it is without having to obsess about
details that some of us may not even notice.
So for for the changes
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
but obviously, we need a way for maintainers to overrule this behavior
without being forced to check in metadata files left and right.
Could we perhaps use a special tag? Or simply overrule ECC if the patch
in question has a Reviewed-by from the maintainer (*not* from a
reviewer) of the package in question?
As for the 'risky' - I agree that it is likely to misunderstood, so
better find a different word to describe this.
--
Ard.
next prev parent reply other threads:[~2020-12-04 16:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 3:21 [PATCH 0/2] OvmfPkg: CI tweaks Laszlo Ersek
2020-12-04 3:21 ` [PATCH 1/2] OvmfPkg: start using the ECC plugin exception list Laszlo Ersek
2020-12-04 4:05 ` [edk2-devel] " Sean
2020-12-04 15:22 ` Laszlo Ersek
2020-12-04 15:36 ` Laszlo Ersek
2020-12-04 16:05 ` Ard Biesheuvel [this message]
2020-12-08 1:56 ` Laszlo Ersek
2020-12-08 2:10 ` James Bottomley
2020-12-08 7:05 ` Ard Biesheuvel
2020-12-08 18:45 ` Sean
2020-12-10 8:23 ` Laszlo Ersek
2020-12-04 18:28 ` Sean
2020-12-08 1:46 ` Laszlo Ersek
2020-12-04 3:21 ` [PATCH 2/2] OvmfPkg: add "gGrubFileGuid=Grub" to GuidCheck.IgnoreDuplicates Laszlo Ersek
2020-12-04 12:42 ` Philippe Mathieu-Daudé
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-list 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=6989494d-4dca-6a92-d748-9c413206e781@arm.com \
--to=devel@edk2.groups.io \
/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