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

["Sean" <spbrogan@outlook.com>]

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.
> 
> 
> 
> 
> 
>