Hi Tomas, Tested this patch series and didn't face any issues. Tested-by: Tanmay Jagdale <tanmay.jagdale@...>

Reviewed-by: Ard Biesheuvel <ard.biesheuvel@...> Pushed as 879f483ce455..663c3108f730 Thanks all,

Reviewed-by: Ard Biesheuvel <ard.biesheuvel@...> Pushed as adcb0c92ca57..879f483ce455 Thanks! And welcome :-)

The initial revision used the letter 'l' instead of the number '1' in "0.10". Signed-off-by: Rebecca Cran <rebecca@...> --- README.md | 2 +- 1 file changed, 1 insertion(+), 1

I presume the CONTRIBUTIONS.txt document in the various tianocore-docs repos is outdated and we no longer need the "Contributed-under: TianoCore Contribution Agreement 1.0"? This patch simply changes

I feel like I'm in *cautious* agreement with this idea. In particular, I'd *only* like those lib class -> lib instance resolutions to be extracted, to DSC include files, that *cannot*

I agree. Without knowing many of the details: The patch references <https://bugzilla.tianocore.org/show_bug.cgi?id=2594>, and that ticket is a TianoCore Feature Request. Additionally, comment#0 on

I agree with doing things properly. Thanks Laszlo

Thanks! We seem to have failed getting a CVE number. I'm unaware of any CVE being assigned to this issue. Thanks Laszlo

Great information, thank you! Exactly the kind that I wanted to hear. Please add this sentence to the commit message (either via a v2 posting, or at merge time, as you see fit). Thanks! Laszlo

I confirm Bret filed a huge bunch of BZs for advertizing the fallout. Again, that was in May. If I look at the bugmail traffic back then, it seems like -- aka "I remember it like" -- Bret ran a

Right, I remember at some point there was a big influx of new BZs for adopting VariablePolicy in edk2-platforms platforms... In fact if I run a search in the TianoCore bugzilla for "variablepolicy",

+1 for this idea. This would allow us to remove a *lot* of boilerplate in the .DSC files, and focus on the libraries that actually matter for the platform at hand.

Hi, all Today, we enter into Hard Feature Freeze phase until edk2-stable202011 tag is created at 2020-11-27. In this phase, there is no feature to be pushed. The critical bug fix is still allowed.

Hey The more I review the code, the more I think we should revisit the usage mode for multiple counters. Some thought: 1) In previous design, it is very clear that we only have one counter. We read

Zhiguang: This proposal can reduce the potential library class dependency. Each package has its xxxPkgLib.dsc.inc file that includes the library instances from this package. Platform DSC can

@Yao, Jiewen, that should be correct. I’m not so sure that this is a great idea. If a platform is consuming entire core packages en masse, that feels like a recipe for disaster (or a platform

Andrei: If you know the broken platforms, you can also contribute the patch to fix them. For this patch, it has passed the code review. The comment is to update the commit message with

I like this idea. MinPlatform also adopt the same strategy - define common stuff in a dsc include file @

I agree with Liming. I recommend we follow the code-freeze process. "By the date of the soft feature freeze, developers must have sent their patches to the mailing list and received positive