From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web10.2435.1607392601203655127 for ; Mon, 07 Dec 2020 17:56:41 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iPh/sFNE; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607392600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=it/oeGcnkt1gn146ve6w6XqhGBKpJBdIQAmBHRi6yWk=; b=iPh/sFNE7glTMYgDTrkXTXq55u0tDOn6aTXpbQVx403LoYiNqn9nJWIHmL8rOGJtdJY2n6 IUIhDdIwfk0SmDDrZ6tZbwMqJouEPBuXmKi26Z+Ejy6uMAxIpKasAa/IJE/OjW38BzBsVL iNWK7Q5r7SN2PvSig+GJYsCNJeFuzOA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-410-qJdPCKssOQm5UziM9ySbyQ-1; Mon, 07 Dec 2020 20:56:36 -0500 X-MC-Unique: qJdPCKssOQm5UziM9ySbyQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 32C03180A089; Tue, 8 Dec 2020 01:56:35 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-30.ams2.redhat.com [10.36.112.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 45D716E406; Tue, 8 Dec 2020 01:56:33 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 1/2] OvmfPkg: start using the ECC plugin exception list To: Ard Biesheuvel , Sean Brogan , devel@edk2.groups.io, James Bottomley Cc: Jordan Justen , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Tom Lendacky , "Leif Lindholm (Nuvia address)" References: <20201204032116.31321-1-lersek@redhat.com> <20201204032116.31321-2-lersek@redhat.com> <7c57b6dc-de1a-8f2b-9b40-c1faf9b46bfe@redhat.com> <6989494d-4dca-6a92-d748-9c413206e781@arm.com> From: "Laszlo Ersek" Message-ID: <3b931320-5afb-0dae-e8d2-f2e56be88177@redhat.com> Date: Tue, 8 Dec 2020 02:56:32 +0100 MIME-Version: 1.0 In-Reply-To: <6989494d-4dca-6a92-d748-9c413206e781@arm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 12/04/20 17:05, Ard Biesheuvel wrote: > 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, I haven't forgotten that you don't like my overlong commit messages. In this case, I diverged because I expected fierce resistance from contributors that like ECC, and figured I'd bring the evidence in advance. > 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 > > but obviously, we need a way for maintainers to overrule this behavior > without being forced to check in metadata files left and right. 100% this! Worse -- if I understand correctly! -- such CI config changes don't even take effect for a patch series if they are themselves part of the series. So it's not like I can just prepend such a patch to a series that I'm about to merge but ECC doesn't like -- I need to get the CI config changes reviewed and merged *separately*. Tremendous waste of time. > > 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. > Yeah, let me drop this one patch and see if we can disable ECC globally, or implement a github label to disable it. James, is it OK if we delay merging of your v3 series a bit? Ard, does your R-b apply to the second patch (including its commit message)? GuidCheck is a useful plugin, and the exception is indeed by design. ... I would still much prefer of course if that patch (= the exception to GuidCheck) could simply be included in James's series. Thanks, Laszlo