From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web11.10234.1600856243144398673 for ; Wed, 23 Sep 2020 03:17:23 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 76003D6E; Wed, 23 Sep 2020 03:17:22 -0700 (PDT) Received: from [192.168.1.81] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 954CB3F718; Wed, 23 Sep 2020 03:17:20 -0700 (PDT) Subject: Re: [edk2-devel] [EXTERNAL] [PATCH v8 00/14] Add the VariablePolicy feature To: Laszlo Ersek , devel@edk2.groups.io, bret.barkelew@microsoft.com, Bret Barkelew Cc: "Yao, Jiewen" , Dandan Bi , Chao Zhang , Jian J Wang , Hao A Wu , "liming.gao" , Jordan Justen , Andrew Fish , "Ni, Ray" References: <20200923060748.3795-1-bret.barkelew@microsoft.com> <1d4ef977-beb8-f7de-a4f9-4137dd23ed50@arm.com> From: "Ard Biesheuvel" Message-ID: <64b7b95c-0a8b-9ab1-8e85-ccc0610d6bad@arm.com> Date: Wed, 23 Sep 2020 12:17:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/23/20 12:04 PM, Laszlo Ersek wrote: > On 09/23/20 11:43, Laszlo Ersek wrote: >> On 09/23/20 11:22, Ard Biesheuvel wrote: >>> On 9/23/20 10:45 AM, Laszlo Ersek wrote: >>>> On 09/23/20 08:12, Bret Barkelew via groups.io wrote: >>>>> To whom it may concern, >>>>> This is as done as it=E2=80=99s going to get. >>>>> >>>>> Thank you all for your help! >>>> >>>> Seems like it's been fully reviewed. If that's the case -- do you wa= nt >>>> me to merge it? >>>> >>>> (Asking because the series modifies multiple packages, so there isn'= t a >>>> maintainer that's uniquely responsible for merging the series.) >>>> >>> >>> Yes, please. This has been going on long enough. >>> >>> Only question I have is breakage in edk2-platforms - it seems that mo= st >>> platforms there are broken atm anyway due to the RngLib change having >>> been merged, but it would be good to have an idea what the status is = there. >>> >> >> Judged from patches 05 through 08, the platforms in edk2-platforms are >> going to need some new lib class resolutions. Therefore I think we mig= ht >> have to merge this in two parts: >> >> - patches 01-08 in the first go, >> - [update edk2-platforms to mimick patches 05-08], >> - patches 09-14 in the second round. >> >> If Bret is OK with that, I can start merging 01-08 soon. >> >> (In theory, we could merge patches 05-08 as a part of the second round= , >> because technically, edk2-platforms only need 01-04. However, if some >> commit messages in edk2-platforms would like to reference *example >> platform code* from edk2, then having stable commit hashes for patches >> 05-08 in edk2 would be useful. Hence my suggestion to include 05-08 in >> the first round of edk2 merging.) >=20 > ... on a second thought, we could merge this series in a single PR as > well; only edk2-platforms would have to advance its edk2 submodule > reference in two stages: >=20 > - first advance the submodule to patch#8, > - then update its own platform DSC files with the new lib instances, > - then advance the edk2 submodule again, to patch#14. >=20 > If that works for you, I think we should merge this edk2 set in one go > -- less work for me, and much more intuitive when viewed from the edk2 > side. (The series would not be stuck in some half-merged state for any > time at all.) >=20 We don't actually use git submodules there, so this does not work. But I am fine with just merging this, as edk2-platforms has been=20 reported to be in broken state anyway.