1. Messages
  2. [EXTERNAL] [PATCH v8 00/14] Add the VariablePolicy feature

Re: [EXTERNAL] [PATCH v8 00/14] Add the VariablePolicy feature

Sean
 

Ard/Laszlo/Samer (since you reported issue with RngLib),

Is now the time to start a discussion about using submodules or at least tracked dependencies in edk2-platforms. The way it stands the only thing you can use to correlate the two are the timestamp of the commit. This means that the history of edk2-platforms will not actually be any different if you merge into edk2 as a two part series or one.

This has been a major pain point as someone who wants to use edk2-platforms downstream.

Another benefit of tracked dependencies is that each platform or group of commonly managed platforms would move their dependencies as they incorporate any edk2 change. This also gives visibility into the maintenance and status of a platform.

Thanks
Sean

On 9/23/2020 3:17 AM, Ard Biesheuvel wrote:
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’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.)
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 reported to be in broken state anyway.
Join devel@edk2.groups.io to automatically receive all group messages.