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.web11.10008.1600855496610559829 for ; Wed, 23 Sep 2020 03:04:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Dv6l3/xl; 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=1600855495; 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=y7NTp057ZDgOrtlPa57dP39RukAsaS8aVHqaaZ+zbpw=; b=Dv6l3/xlajqiuMabin6FVMFIM9dW4O+D9bg9hrxvMHFKbecI00R4MJL524PYbYyrgDeDDW pLWzjj3yEglUsBajwNTwGdQVWw0Wn0ue4gdTEZUPbVHvEipnQurX7fUDJz3JUUj60VIiuW 2jUNxoQGECvjWt+sJTMQ+fPbLTBT7w4= 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-152-d3Ass2J2MICg8HL93rr8WQ-1; Wed, 23 Sep 2020 06:04:53 -0400 X-MC-Unique: d3Ass2J2MICg8HL93rr8WQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B6C5F81F004; Wed, 23 Sep 2020 10:04:51 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-233.ams2.redhat.com [10.36.112.233]) by smtp.corp.redhat.com (Postfix) with ESMTP id C4880100238C; Wed, 23 Sep 2020 10:04:48 +0000 (UTC) Subject: Re: [edk2-devel] [EXTERNAL] [PATCH v8 00/14] Add the VariablePolicy feature From: "Laszlo Ersek" To: Ard Biesheuvel , 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> Message-ID: Date: Wed, 23 Sep 2020 12:04:47 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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-Transfer-Encoding: 8bit Content-Language: en-US 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’s going to get. >>>> >>>> Thank you all for your help! >>> >>> Seems like it's been fully reviewed. If that's the case -- do you want >>> 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 most >> 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 might > 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.) ... 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: - 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. 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.) Thanks Laszlo