From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id D62B8740032 for ; Sun, 29 Oct 2023 13:30:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=flmh63X3rmCPDqCtLzbiaoySfmamZG5hmZizxrTD+60=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698586247; v=1; b=EbLX1zMRnpizA894fEC7z9d0W09F7nAdQAvicAJIEX+Jhn4ANF3i23Y6nDQhK8j6kqK3kC5c FoNlSiCzYtYqrR1HtWdQDKa7HmfXa6/cRU4tARLajCBKZl+YmyB4v0Xa7Y+rCNlBNWSV4RKlt1C F/HI1NgtXDYIm8MsGKHzXJb4= X-Received: by 127.0.0.2 with SMTP id 1pZ6YY7687511xJD2tYMJUMv; Sun, 29 Oct 2023 06:30:47 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.72385.1698586246817218896 for ; Sun, 29 Oct 2023 06:30:47 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-512-MV65nzKQPFSk_q5-Xg6GdA-1; Sun, 29 Oct 2023 09:30:32 -0400 X-MC-Unique: MV65nzKQPFSk_q5-Xg6GdA-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EE72129AA39B; Sun, 29 Oct 2023 13:30:30 +0000 (UTC) X-Received: from [10.39.192.79] (unknown [10.39.192.79]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1F3B61C060AE; Sun, 29 Oct 2023 13:30:26 +0000 (UTC) Message-ID: Date: Sun, 29 Oct 2023 14:30:25 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members To: devel@edk2.groups.io, pedro.falcato@gmail.com, michael.d.kinney@intel.com Cc: Andrew Fish , Leif Lindholm , Andrei Warkentin , Catharine West , Dandan Bi , Daniel Schaefer , David Woodhouse , Debkumar De , Eric Dong , Guomin Jiang , Hao A Wu , James Bottomley , Jian J Wang , Jordan Justen , Julien Grall , Peter Grehan , Qi Zhang , Ray Han Lim Ng , Stefan Berger , Wenxing Hou , Xiaoyu Lu References: <20231028192330.1031-1-michael.d.kinney@intel.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: v6tFaplb5EtBUaGqu5Mod4kMx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=EbLX1zMR; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 10/29/23 03:16, Pedro Falcato wrote: > On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney > wrote: >> >> Over the past few months, all the of the Maintainers and >> Reviewers listed in Maintainers.txt have been contacted to make >> sure Maintainers.txt accurately represents the TianoCore >> community members that are actively participating in their >> roles. Based on specific feedback, bounced emails, and no >> responses, updates have been made. >> >> * RISCV64: Daniel Schaefer replaced with Andrei Warkentin >> * ArmVirtPkg Xen has no remaining reviewers and review >> responsibility defaults to ArmVirtPkg Maintainers/Reviewers. >> * ACPI modules related to S3 has no remaining reviewers and >> review responsibility defaults to MdeModulePkg Maintainers/ >> Reviewers. >> * OVMF CSM modules has no remaining reviewers and review >> responsibility defaults to OvmfPkg Maintainers/Reviewers. >> * Bounce: Chan Laura >> * Many smaller updates removing individuals that are no >> longer involved or have replacement coverage. > > Mike, > > Thank you so much for doing this thankless task. Some comments: > >> diff --git a/Maintainers.txt b/Maintainers.txt >> index 3f40cdeb5554..2b03ccbe54aa 100644 >> --- a/Maintainers.txt >> +++ b/Maintainers.txt >> @@ -93,7 +93,7 @@ M: Sami Mujawar [samimujawar] >> RISCV64 >> F: */RiscV64/ >> M: Sunil V L [vlsunil] >> -R: Daniel Schaefer [JohnAZoidberg] >> +R: Andrei Warkentin [andreiw] >> >> LOONGARCH64 >> F: */LoongArch64/ >> @@ -157,16 +157,6 @@ R: Leif Lindholm [leiflindholm] >> R: Sami Mujawar [samimujawar] >> R: Gerd Hoffmann [kraxel] >> >> -ArmVirtPkg: modules used on Xen >> -F: ArmVirtPkg/ArmVirtXen.* >> -F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/ >> -F: ArmVirtPkg/Library/XenVirtMemInfoLib/ >> -F: ArmVirtPkg/PrePi/ >> -F: ArmVirtPkg/XenAcpiPlatformDxe/ >> -F: ArmVirtPkg/XenPlatformHasAcpiDtDxe/ >> -F: ArmVirtPkg/XenioFdtDxe/ >> -R: Julien Grall [jgrall] > > ArmVirtPkg Xen modules seize to have a dedicated maintainer. Can the > generic ArmVirtPkg maintainers handle *more code* (particularly, > functionality that's not trivial to test, unless you actively use > Xen)? An alternative to removing this entire section is to replace Julien's line with the following status line: S: Orphan The definition in Maintainers.txt is: Orphan: No current maintainer [but maybe you could take the role as you write your new code]. I think this might be clearer for all three of: contributors, consumers, and existent maintainers. - Contributors: An ArmVirtPkg maintainer may techincally merge your code, but you won't get substantive feedback - Consumers: you can build and run this code, but if it breaks, you get to keep both parts - Existent ArmVirtPkg maintainers: you can rest assured in the knowledge that you are not saddled with deep technical reviews for this subsystem that you can't even boot in your environment. You're only responsible for the technical act of merging patches. > >> BaseTools >> F: BaseTools/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools >> @@ -187,8 +177,7 @@ F: CryptoPkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg >> M: Jiewen Yao [jyao1] >> M: Yi Li [liyi77] >> -R: Xiaoyu Lu [xiaoyuxlu] >> -R: Guomin Jiang [guominjia] >> +R: Wenxing Hou [Wenxing-hou] >> >> DynamicTablesPkg >> F: DynamicTablesPkg/ >> @@ -202,7 +191,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg >> M: Leif Lindholm [leiflindholm] >> M: Ard Biesheuvel [ardbiesheuvel] >> M: Abner Chang [changab] >> -R: Daniel Schaefer [JohnAZoidberg] >> >> EmulatorPkg >> F: EmulatorPkg/ >> @@ -228,7 +216,6 @@ F: FmpDevicePkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg >> M: Liming Gao [lgao4] >> M: Michael D Kinney [mdkinney] >> -R: Guomin Jiang [guominjia] >> R: Wei6 Xu [xuweiintel] >> >> IntelFsp2Pkg >> @@ -237,7 +224,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg >> M: Chasel Chiu [ChaselChiu] >> M: Nate DeSimone [nate-desimone] >> M: Duggapu Chinni B [cbduggap] >> -M: Ray Han Lim Ng [rayhanlimng] >> R: Star Zeng [lzeng14] >> R: Ted Kuo [tedkuo1] >> R: Ashraf Ali S [AshrafAliS] >> @@ -258,7 +244,6 @@ R: Susovan Mohapatra [susovanmohapatra] >> MdeModulePkg >> F: MdeModulePkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg >> -M: Jian J Wang [jwang36] >> M: Liming Gao [lgao4] > > MdeModulePkg now only has a single maintainer (Liming, who also > handles a myriad of other tasks and packages) This leads me to my main point: it may be time for edk2 to adopt a leaner contribution process. We can insist on no patch going in without maintainer approval, but that -- i.e., maintainer authority -- only works as long as it goes hand in hand with maintainer responsibility: timely reviews. If the community cannot offer enough working hours for reviewing patches for a subsystem, then the requirements to contribute to that subsystem should be relaxed. The other alternative is that the subsystem goes into stasis, where it becomes effectively impossible to contribute to a subsystem. (NB this "relaxation of contribution rules" is entirely orthogonal to using a mailing list vs. github pull requests. I still strongly prefer the mailing list.) So maybe we could say, if there is no patch review for like 7 working days (approx. one and half calendar weeks), then the patch should be merged by default. Put differently, switch from "rejected by default" to "accepted by default". By the way, I would like to assist with MdeModulePkg reviews. I'm not sure if I can *commit* to that, but right now, that is my intent. (As always, I see maintainership / reviewership as a service, not as a privilege.) >> >> MdeModulePkg: ACPI modules >> @@ -268,15 +253,6 @@ R: Zhiguang Liu [LiuZhiguang001] >> R: Dandan Bi [dandanbi] >> R: Liming Gao [lgao4] >> >> -MdeModulePkg: ACPI modules related to S3 >> -F: MdeModulePkg/*LockBox*/ >> -F: MdeModulePkg/Include/*BootScript*.h >> -F: MdeModulePkg/Include/*LockBox*.h >> -F: MdeModulePkg/Include/*S3*.h >> -F: MdeModulePkg/Library/*S3*/ >> -R: Hao A Wu [hwu25] >> -R: Eric Dong [ydong10] >> - >> MdeModulePkg: BDS modules >> F: MdeModulePkg/*BootManager*/ >> F: MdeModulePkg/Include/Library/UefiBootManagerLib.h Same story could apply here -- we could orphan S3 stuff as well. However, I can't deny I'm quite cranky at the thought of S3 breaking, at least in my trusty old configurations, so I'd certainly like to keep an eye on the S3 modules -- even if that only consisted of me regression-testing patches under OVMF (and not providing "expert feedback" on patch contents). >> @@ -326,7 +302,6 @@ F: MdeModulePkg/Library/DxeSecurityManagementLib/ >> F: MdeModulePkg/Universal/PCD/ >> F: MdeModulePkg/Universal/PlatformDriOverrideDxe/ >> F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c >> -R: Dandan Bi [dandanbi] >> R: Liming Gao [lgao4] > > Down to one reviewer. I'll try to assist whenever I can, wherever I notice something interesting -- I'm quite sure I'm going to be overwhelmed incredibly quickly, but at least I have that intent right now. > >> >> MdeModulePkg: Device and Peripheral modules >> @@ -346,12 +321,10 @@ F: MdeModulePkg/Include/Ppi/StorageSecurityCommand.h >> F: MdeModulePkg/Include/Protocol/Ps2Policy.h >> F: MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/ >> F: MdeModulePkg/Universal/PcatSingleSegmentPciCfg2Pei/ >> -R: Hao A Wu [hwu25] >> R: Ray Ni [niruiyu] > > Device and bus related code is down to one reviewer. > >> >> MdeModulePkg: Disk modules >> F: MdeModulePkg/Universal/Disk/ >> -R: Hao A Wu [hwu25] >> R: Ray Ni [niruiyu] >> R: Zhichao Gao [ZhichaoGao] >> >> @@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/ >> F: MdeModulePkg/Library/FmpAuthenticationLibNull/ >> F: MdeModulePkg/Universal/Esrt*/ >> R: Liming Gao [lgao4] >> -R: Guomin Jiang [guominjia] > > One reviewer > >> >> MdeModulePkg: HII and UI modules >> F: MdeModulePkg/*FileExplorer*/ >> @@ -383,7 +355,6 @@ F: MdeModulePkg/Universal/DisplayEngineDxe/ >> F: MdeModulePkg/Universal/DriverSampleDxe/ >> F: MdeModulePkg/Universal/SetupBrowserDxe/ >> R: Dandan Bi [dandanbi] >> -R: Eric Dong [ydong10] > > One reviewer >> >> MdeModulePkg: Management Mode (MM, SMM) modules >> F: MdeModulePkg/*Smi*/ >> @@ -395,10 +366,7 @@ R: Ray Ni [niruiyu] >> >> MdeModulePkg: Pei Core >> F: MdeModulePkg/Core/Pei/ >> -R: Dandan Bi [dandanbi] >> R: Liming Gao [lgao4] >> -R: Debkumar De [dde01] >> -R: Catharine West [catharine-intl] > > The *PEI core* is now down to one reviewer. > >> I've recently reviewed a PEI Core patch set! :) >> MdeModulePkg: Reset modules >> F: MdeModulePkg/*Reset*/ >> @@ -424,7 +392,6 @@ F: MdeModulePkg/Include/*/*Var*.h >> F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h >> F: MdeModulePkg/Include/Protocol/SwapAddressRange.h >> F: MdeModulePkg/Universal/FaultTolerantWrite*/ >> -R: Hao A Wu [hwu25] >> R: Liming Gao [lgao4] > > ditto This is under "MdeModulePkg: UEFI Variable modules". Microsoft developers have contributed lots of UEFI variable-related stuff to edk2. Invite them to co-maintain / co-review? >> >> MdeModulePkg: Universal Payload definitions >> @@ -437,7 +404,6 @@ F: MdeModulePkg/Library/TraceHubDebugSysTLib/ >> F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h >> M: Gua Guo [gguo11837463] >> M: Prakashan Krishnadas Veliyathuparambil [kprakas2] >> -R: Chan Laura [lauracha] >> R: K N Karthik [karthikkabbigere1] >> >> MdeModulePkg: USB Network modules >> @@ -497,7 +463,6 @@ F: OvmfPkg/ >> W: http://www.tianocore.org/ovmf/ >> M: Ard Biesheuvel [ardbiesheuvel] >> M: Jiewen Yao [jyao1] >> -R: Jordan Justen [jljusten] >> R: Gerd Hoffmann [kraxel] >> S: Maintained >> >> @@ -513,7 +478,6 @@ F: OvmfPkg/Library/PlatformBootManagerLibBhyve/ >> F: OvmfPkg/Library/ResetSystemLib/BaseResetShutdownBhyve.c >> F: OvmfPkg/Library/ResetSystemLib/BaseResetSystemLibBhyve.inf >> R: Rebecca Cran [bcran] >> -R: Peter Grehan [grehan-freebsd] >> R: Corvin Köhne [corvink] >> >> OvmfPkg: cloudhv-related modules >> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h >> F: OvmfPkg/Library/ResetSystemLib/*Microvm.* >> R: Gerd Hoffmann [kraxel] >> >> -OvmfPkg: CSM modules >> -F: OvmfPkg/Csm/ >> -R: David Woodhouse [dwmw2] > > 0 people dedicated to OVMF CSM (although relatively low maintenance > overhead, from what it seems) In my view, we should orphan the CSM now. Or maybe even better, mark it as Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. Mid-term, we should figure out a "feature deprecation process" for edk2, and then remove the CSM altogether. Other projects I'm somewhat familiar with have deprecation policies; they announce / document a subsystem deprecated in one release, and then a number of releases later, the subsystem is removed completely. This gives users notice ahead of time, and lets them migrate to different solutions gradually. Lots of edk2 code have been removed already (Itanium support, Intel Framework stuff, etc); we didn't observe any deprecation policy back then. I don't know if there was any backlash from that. I'd be OK with removing the CSM at once (well, not in edk2-stable202311, but in the release after), but that might not be perceived as overly polite. >> - >> OvmfPkg: Confidential Computing >> F: OvmfPkg/AmdSev/ >> F: OvmfPkg/AmdSevDxe/ >> @@ -545,7 +505,6 @@ F: OvmfPkg/PlatformPei/AmdSev.c >> F: OvmfPkg/ResetVector/ >> F: OvmfPkg/Sec/ >> R: Erdem Aktas [ruleof2] >> -R: James Bottomley [jejb] >> R: Jiewen Yao [jyao1] >> R: Min Xu [mxu9] >> R: Tom Lendacky [tlendacky] It's good for the project that CoCo has several reviewers still. (It's one of those areas that I categorically refuse to look at. I might make an exception for base SEV, but SEV-ES is quite unlikely, and SEV-SNP and TDX are out of question for me.) >> @@ -568,7 +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/ >> F: OvmfPkg/PlatformPei/ClearCache.c >> F: OvmfPkg/Tcg/ >> R: Marc-André Lureau [elmarco] >> -R: Stefan Berger [stefanberger] > > One reviewer I'll attempt to help here (TCG/TPM2) if necessary; even if that's going to boil down to summon more knowledgeable folks from Red Hat :) >> >> OvmfPkg: Xen-related modules >> F: OvmfPkg/Include/Guid/XenBusRootDevice.h >> @@ -597,7 +555,6 @@ F: OvmfPkg/XenPlatformPei/ >> F: OvmfPkg/XenPvBlkDxe/ >> F: OvmfPkg/XenResetVector/ >> R: Anthony Perard [tperard] >> -R: Julien Grall [jgrall] > > One reviewer Not necessarily a bad thing, my impression is that OVMF Xen has seen very little churn. At least it's not unmaintained. >> >> OvmfPkg: RISC-V Qemu Virt Platform >> F: OvmfPkg/RiscVVirt >> @@ -627,7 +584,6 @@ SecurityPkg >> F: SecurityPkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/SecurityPkg >> M: Jiewen Yao [jyao1] >> -M: Jian J Wang [jwang36] >> >> SecurityPkg: Secure boot related modules >> F: SecurityPkg/Library/DxeImageVerificationLib/ >> @@ -637,7 +593,6 @@ R: Min Xu [mxu9] >> >> SecurityPkg: Tcg related modules >> F: SecurityPkg/Tcg/ >> -R: Qi Zhang [qizhangz] >> R: Rahul Kumar [rahul1-kumar] > > ditto This still falls under Jiewen's maintainership of SecurityPkg, so I don't perceive it as very risky. >> >> ShellPkg >> @@ -648,12 +603,10 @@ M: Zhichao Gao [ZhichaoGao] >> SignedCapsulePkg >> F: SignedCapsulePkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg >> -M: Jian J Wang [jwang36] > > Unmaintained Probably best to mark it as orphaned then! > >> >> SourceLevelDebugPkg >> F: SourceLevelDebugPkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg >> -M: Hao A Wu [hwu25] > > Unmaintained >> >> StandaloneMmPkg >> F: StandaloneMmPkg/ I'd orphan this one as well. For one, I've never gotten SOURCE_DEBUG_ENABLE to work in OVMF. (I'd not go as far as removing it, I'm sure this module has many downstream users!) >> @@ -664,7 +617,6 @@ M: Ray Ni [niruiyu] >> UefiCpuPkg >> F: UefiCpuPkg/ >> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg >> -M: Eric Dong [ydong10] >> M: Ray Ni [niruiyu] >> R: Rahul Kumar [rahul1-kumar] >> R: Gerd Hoffmann [kraxel] >> @@ -672,7 +624,6 @@ R: Gerd Hoffmann [kraxel] >> UefiCpuPkg: Sec related modules >> F: UefiCpuPkg/SecCore/ >> F: UefiCpuPkg/ResetVector/ >> -R: Debkumar De [dde01] >> R: Catharine West [catharine-intl] > > One reviewer. Not necessarily alarming IMO, UefiCpuPkg in general is not neglected (Gerd is listed, and I would like to keep an eye on it too). So I'd rather phrase this one as "we even have a dedicated reviewer for 'UefiCpuPkg: Sec'!" :) > > Some brief LoC (taking into account code, blank lines and comments) > stats over some of the affected packages/modules: > SignedCapsulePkg - 6,836 LoC > SourceLevelDebugPkg - 15,208 LoC > MdeModulePkg - 616,591 LoC (!!) > Bus/ - 216,268 LoC (!!!) Yep, these two are heavy-weights. > (HII and UI was tough to actually measure, but I'm relatively sure > it's 100,000+ LoC!) HII is unfortunately terribly difficult. The documentation is very lacking IMO (in the spec). I tried to read Tim Lewis's blog posts on it: https://uefi.blogspot.com/search/label/UEFI%20HII but I didn't get far. It feels like one of the most over-engineered (or at least most complex) parts of UEFI / edk2. I once authored OvmfPkg/PlatformDxe, because Jordan really wanted me to; ever since I've been steering as clear of it as I could :) At least Dandan continues as a designated reviewer for HII! > Core/Pei - 11,985 LoC > SecurityPkg/Tcg - 26,275 LoC > > (sidenote: It'd be interesting to see the numbers from a personnel PoV > - Person X is responsible for N lines of code, etc) > It seems obvious (as a result of your great work!) that lots of people > really are stretched incredibly thin. > > Taking everything into account, I have two questions: > 1) Should we go through these changes (that effectively reflect > reality, that much I understand) and see what needs to be cut from > EDK2 (i.e do we have an overabundance of features)? I'd say "yes". To reiterate, - I'd propose explicitly marking orphaned subsystems as such, rather than merging them silently into parent subsystems, - certainly removing some subsystems, but for that, a "staged" deprecation policy would be most polite. > 2) What's the call for action here? Should people submit themselves as > new reviewers/maintainers of poorly maintained/reviewed code? Themselves and each other, yes. I'll re-raise my point about relaxing the contribution conditions too -- given this state, I'd propose a "merge by default" approach, with a reasonable timeout. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110258): https://edk2.groups.io/g/devel/message/110258 Mute This Topic: https://groups.io/mt/102245264/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-