* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
@ 2023-10-29 2:16 ` Pedro Falcato
2023-10-29 8:05 ` Yao, Jiewen
` (2 more replies)
2023-10-29 21:58 ` Stefan Berger
` (7 subsequent siblings)
8 siblings, 3 replies; 32+ messages in thread
From: Pedro Falcato @ 2023-10-29 2:16 UTC (permalink / raw)
To: devel, michael.d.kinney
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
On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
<michael.d.kinney@intel.com> 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 <laura.chan@intel.com>
> * 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 <sami.mujawar@arm.com> [samimujawar]
> RISCV64
> F: */RiscV64/
> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>
> LOONGARCH64
> F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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)?
> 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 <jiewen.yao@intel.com> [jyao1]
> M: Yi Li <yi1.li@intel.com> [liyi77]
> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
>
> DynamicTablesPkg
> F: DynamicTablesPkg/
> @@ -202,7 +191,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Abner Chang <abner.chang@amd.com> [changab]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>
> EmulatorPkg
> F: EmulatorPkg/
> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
>
> IntelFsp2Pkg
> @@ -237,7 +224,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> @@ -258,7 +244,6 @@ R: Susovan Mohapatra <susovan.mohapatra@intel.com> [susovanmohapatra]
> MdeModulePkg
> F: MdeModulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
MdeModulePkg now only has a single maintainer (Liming, who also
handles a myriad of other tasks and packages)
>
> MdeModulePkg: ACPI modules
> @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]
> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> -
> MdeModulePkg: BDS modules
> F: MdeModulePkg/*BootManager*/
> F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -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 <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
Down to one reviewer.
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
Device and bus related code is down to one reviewer.
>
> MdeModulePkg: Disk modules
> F: MdeModulePkg/Universal/Disk/
> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>
> @@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> F: MdeModulePkg/Universal/Esrt*/
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Guomin Jiang <guomin.jiang@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
One reviewer
>
> MdeModulePkg: Management Mode (MM, SMM) modules
> F: MdeModulePkg/*Smi*/
> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Pei Core
> F: MdeModulePkg/Core/Pei/
> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> -R: Catharine West <catharine.west@intel.com> [catharine-intl]
The *PEI core* is now down to one reviewer.
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
ditto
>
> MdeModulePkg: Universal Payload definitions
> @@ -437,7 +404,6 @@ F: MdeModulePkg/Library/TraceHubDebugSysTLib/
> F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> M: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
>
> MdeModulePkg: USB Network modules
> @@ -497,7 +463,6 @@ F: OvmfPkg/
> W: http://www.tianocore.org/ovmf/
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> R: Corvin Köhne <corvink@freebsd.org> [corvink]
>
> OvmfPkg: cloudhv-related modules
> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>
> -OvmfPkg: CSM modules
> -F: OvmfPkg/Csm/
> -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
0 people dedicated to OVMF CSM (although relatively low maintenance
overhead, from what it seems)
> -
> 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 <erdemaktas@google.com> [ruleof2]
> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> R: Min Xu <min.m.xu@intel.com> [mxu9]
> R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
> @@ -568,7 +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> F: OvmfPkg/PlatformPei/ClearCache.c
> F: OvmfPkg/Tcg/
> R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
One reviewer
>
> 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 <anthony.perard@citrix.com> [tperard]
> -R: Julien Grall <julien@xen.org> [jgrall]
One reviewer
>
> 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 <jiewen.yao@intel.com> [jyao1]
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SecurityPkg: Secure boot related modules
> F: SecurityPkg/Library/DxeImageVerificationLib/
> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
>
> SecurityPkg: Tcg related modules
> F: SecurityPkg/Tcg/
> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
ditto
>
> ShellPkg
> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> SignedCapsulePkg
> F: SignedCapsulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
Unmaintained
>
> SourceLevelDebugPkg
> F: SourceLevelDebugPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
> -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
Unmaintained
>
> StandaloneMmPkg
> F: StandaloneMmPkg/
> @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu]
> UefiCpuPkg
> F: UefiCpuPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> UefiCpuPkg: Sec related modules
> F: UefiCpuPkg/SecCore/
> F: UefiCpuPkg/ResetVector/
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> R: Catharine West <catharine.west@intel.com> [catharine-intl]
One reviewer.
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 (!!!)
(HII and UI was tough to actually measure, but I'm relatively sure
it's 100,000+ LoC!)
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)?
2) What's the call for action here? Should people submit themselves as
new reviewers/maintainers of poorly maintained/reviewed code?
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110256): https://edk2.groups.io/g/devel/message/110256
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 2:16 ` Pedro Falcato
@ 2023-10-29 8:05 ` Yao, Jiewen
2023-10-29 13:48 ` Laszlo Ersek
2023-10-29 13:30 ` Laszlo Ersek
2023-10-30 7:38 ` Ng, Ray Han Lim
2 siblings, 1 reply; 32+ messages in thread
From: Yao, Jiewen @ 2023-10-29 8:05 UTC (permalink / raw)
To: devel@edk2.groups.io, pedro.falcato@gmail.com, Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
Those are great questions. I also would like to understand:
1) What is definition of "actively participating in their roles"?
Is there any enforcement or just volunteer work?
2) What is role and *responsibility* of Reviewer role? Is it documented somewhere?
Per my observation, some assigned reviewers have never reviewed any patch in history or provided valuable feedback. To me, reviewer role seems more like a notification instead of really review something. Is that our purpose?
While Laszlo contributed a lots in Tianocore community, he is really a good "reviewer", although he has no such title.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
> Sent: Sunday, October 29, 2023 10:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>;
> Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>;
> De, Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> James Bottomley <jejb@linux.ibm.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>;
> Peter Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng,
> Ray Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1
> <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
>
> On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
> <michael.d.kinney@intel.com> 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 <laura.chan@intel.com>
> > * 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 <sami.mujawar@arm.com>
> [samimujawar]
> > RISCV64
> > F: */RiscV64/
> > M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> > -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> > +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
> >
> > LOONGARCH64
> > F: */LoongArch64/
> > @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> [leiflindholm]
> > R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> > R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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)?
>
> > 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 <jiewen.yao@intel.com> [jyao1]
> > M: Yi Li <yi1.li@intel.com> [liyi77]
> > -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> > -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> > +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
> >
> > DynamicTablesPkg
> > F: DynamicTablesPkg/
> > @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> > M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> > M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> > M: Abner Chang <abner.chang@amd.com> [changab]
> > -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> >
> > EmulatorPkg
> > F: EmulatorPkg/
> > @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> > W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> > M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> > -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> > R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
> >
> > IntelFsp2Pkg
> > @@ -237,7 +224,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> > M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> > M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> > M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> > -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> > R: Star Zeng <star.zeng@intel.com> [lzeng14]
> > R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> > R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> > @@ -258,7 +244,6 @@ R: Susovan Mohapatra
> <susovan.mohapatra@intel.com> [susovanmohapatra]
> > MdeModulePkg
> > F: MdeModulePkg/
> > W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> > -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> > M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg now only has a single maintainer (Liming, who also
> handles a myriad of other tasks and packages)
> >
> > MdeModulePkg: ACPI modules
> > @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com>
> [LiuZhiguang001]
> > R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> > -R: Eric Dong <eric.dong@intel.com> [ydong10]
> > -
> > MdeModulePkg: BDS modules
> > F: MdeModulePkg/*BootManager*/
> > F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> > @@ -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 <dandan.bi@intel.com> [dandanbi]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> Down to one reviewer.
>
> >
> > 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 <hao.a.wu@intel.com> [hwu25]
> > R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> Device and bus related code is down to one reviewer.
>
> >
> > MdeModulePkg: Disk modules
> > F: MdeModulePkg/Universal/Disk/
> > -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> > R: Ray Ni <ray.ni@intel.com> [niruiyu]
> > R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> >
> > @@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
> > F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> > F: MdeModulePkg/Universal/Esrt*/
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > -R: Guomin Jiang <guomin.jiang@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> > -R: Eric Dong <eric.dong@intel.com> [ydong10]
>
> One reviewer
> >
> > MdeModulePkg: Management Mode (MM, SMM) modules
> > F: MdeModulePkg/*Smi*/
> > @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
> >
> > MdeModulePkg: Pei Core
> > F: MdeModulePkg/Core/Pei/
> > -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > -R: Debkumar De <debkumar.de@intel.com> [dde01]
> > -R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> The *PEI core* is now down to one reviewer.
>
> >
> > 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 <hao.a.wu@intel.com> [hwu25]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> ditto
> >
> > MdeModulePkg: Universal Payload definitions
> > @@ -437,7 +404,6 @@ F: MdeModulePkg/Library/TraceHubDebugSysTLib/
> > F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> > M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> > M: Prakashan Krishnadas Veliyathuparambil
> <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> > -R: Chan Laura <laura.chan@intel.com> [lauracha]
> > R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
> >
> > MdeModulePkg: USB Network modules
> > @@ -497,7 +463,6 @@ F: OvmfPkg/
> > W: http://www.tianocore.org/ovmf/
> > M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> > M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> > -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> > R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> > -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> > R: Corvin Köhne <corvink@freebsd.org> [corvink]
> >
> > OvmfPkg: cloudhv-related modules
> > @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> > F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> > R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >
> > -OvmfPkg: CSM modules
> > -F: OvmfPkg/Csm/
> > -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
>
> 0 people dedicated to OVMF CSM (although relatively low maintenance
> overhead, from what it seems)
> > -
> > 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 <erdemaktas@google.com> [ruleof2]
> > -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> > R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> > R: Min Xu <min.m.xu@intel.com> [mxu9]
> > R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
> > @@ -568,7 +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> > F: OvmfPkg/PlatformPei/ClearCache.c
> > F: OvmfPkg/Tcg/
> > R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> > -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
>
> One reviewer
> >
> > 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 <anthony.perard@citrix.com> [tperard]
> > -R: Julien Grall <julien@xen.org> [jgrall]
>
> One reviewer
> >
> > 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 <jiewen.yao@intel.com> [jyao1]
> > -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >
> > SecurityPkg: Secure boot related modules
> > F: SecurityPkg/Library/DxeImageVerificationLib/
> > @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
> >
> > SecurityPkg: Tcg related modules
> > F: SecurityPkg/Tcg/
> > -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> > R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
>
> ditto
> >
> > ShellPkg
> > @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com>
> [ZhichaoGao]
> > SignedCapsulePkg
> > F: SignedCapsulePkg/
> > W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> > -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> Unmaintained
>
> >
> > SourceLevelDebugPkg
> > F: SourceLevelDebugPkg/
> > W:
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
> > -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
>
> Unmaintained
> >
> > StandaloneMmPkg
> > F: StandaloneMmPkg/
> > @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu]
> > UefiCpuPkg
> > F: UefiCpuPkg/
> > W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> > -M: Eric Dong <eric.dong@intel.com> [ydong10]
> > M: Ray Ni <ray.ni@intel.com> [niruiyu]
> > R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> > R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > UefiCpuPkg: Sec related modules
> > F: UefiCpuPkg/SecCore/
> > F: UefiCpuPkg/ResetVector/
> > -R: Debkumar De <debkumar.de@intel.com> [dde01]
> > R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> One reviewer.
>
> 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 (!!!)
> (HII and UI was tough to actually measure, but I'm relatively sure
> it's 100,000+ LoC!)
> 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)?
> 2) What's the call for action here? Should people submit themselves as
> new reviewers/maintainers of poorly maintained/reviewed code?
>
> --
> Pedro
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110257): https://edk2.groups.io/g/devel/message/110257
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 8:05 ` Yao, Jiewen
@ 2023-10-29 13:48 ` Laszlo Ersek
2023-10-29 14:09 ` Laszlo Ersek
2023-10-29 15:42 ` Yao, Jiewen
0 siblings, 2 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-29 13:48 UTC (permalink / raw)
To: devel, jiewen.yao, pedro.falcato@gmail.com, Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
On 10/29/23 09:05, Yao, Jiewen wrote:
> Those are great questions. I also would like to understand:
>
> 1) What is definition of "actively participating in their roles"?
Here are the definitions of Maintainer and Reviewer, from
"Maintainers.txt":
M: Package Maintainer: Cc address for patches and questions. Responsible
for reviewing and pushing package changes to source control.
R: Package Reviewer: Cc address for patches and questions. Reviewers help
maintainers review code, but don't have push access. A designated Package
Reviewer is reasonably familiar with the Package (or some modules
thereof), and/or provides testing or regression testing for the Package
(or some modules thereof), in certain platforms and environments.
> Is there any enforcement or just volunteer work?
I see the Maintainer role as a service to the community, with some
benefits granted in return. The "service" part should be clear. The
benefit is that you are kept in the loop, and sometimes (when you must)
you *can* say "no". (According to some seasoned reviewers, the one real
power of a maintainer -- not to be abused! -- is "saying no".) A
maintainer that's present helps set the focus, keep regressions out,
gives advice when needed, and so on.
Enforcement would be nice (haha), but it never works. You can't force
people to help, especially if their dayjob instructions oppose their
upstream community responsibilities. That's fine; in such cases my
request is always: if you can't help, then at least don't get in the
way, step down. Don't block people from doing their work by having them
wait for your feedback.
So volunteer work is fine, but as soon as the position grows "fangs" (=
a capacity to make others wait), then it becomes a promise, a
responsibility.
>
> 2) What is role and *responsibility* of Reviewer role? Is it
> documented somewhere?
> Per my observation, some assigned reviewers have never reviewed any
> patch in history or provided valuable feedback. To me, reviewer role
> seems more like a notification instead of really review something. Is
> that our purpose?
I'd say that's pretty close. A reviewer role is a request for keeping
the reviewer in the loop. Maintainers tend to appreciate that, because a
long-term reviewer may provide good insights, test results, and so on.
Trust is super important; a maintainer may push a patch based solely on
a reviewer's positive feedback, due to the latter's experience.
> While Laszlo contributed a lots in Tianocore community, he is really a
> good "reviewer", although he has no such title.
Thanks for the acknowledgement, I appreciate it!
I don't like to hoard titles. I'm sure titles are good for one's career,
but I always see the *promise* (the responsibility) to the community,
first and foremost, that a title encapsulates. It weighs heavily on me.
I loathe disappointing people. For me, not to bear a title is better
than to bear it and not to deliver on it / not to live up to it.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110259): https://edk2.groups.io/g/devel/message/110259
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 13:48 ` Laszlo Ersek
@ 2023-10-29 14:09 ` Laszlo Ersek
2023-10-29 15:42 ` Yao, Jiewen
1 sibling, 0 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-29 14:09 UTC (permalink / raw)
To: devel, jiewen.yao, pedro.falcato@gmail.com, Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
On 10/29/23 14:48, Laszlo Ersek wrote:
> I loathe disappointing people.
English is a tricky language. The above landed as an (unintended)
double-entendre.
I meant: "I hate to disappoint people".
I didn't mean: "I loathe people that are disappointing".
Ouch.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110261): https://edk2.groups.io/g/devel/message/110261
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 13:48 ` Laszlo Ersek
2023-10-29 14:09 ` Laszlo Ersek
@ 2023-10-29 15:42 ` Yao, Jiewen
2023-10-29 16:01 ` James Bottomley
1 sibling, 1 reply; 32+ messages in thread
From: Yao, Jiewen @ 2023-10-29 15:42 UTC (permalink / raw)
To: Laszlo Ersek, devel@edk2.groups.io, pedro.falcato@gmail.com,
Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
> I'd say that's pretty close. A reviewer role is a request for keeping
> the reviewer in the loop.
[Jiewen] I am disappointed on that.
To me, that is NOT a real reviewer. See below description on what is "code review".
https://google.github.io/eng-practices/review/
https://about.gitlab.com/topics/version-control/what-is-code-review/
Our definition seems more like *a notification receiver*, instead of a real code reviewer.
I would say, it is a very misleading definition.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Sunday, October 29, 2023 9:48 PM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> pedro.falcato@gmail.com; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>;
> Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>;
> De, Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> James Bottomley <jejb@linux.ibm.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>;
> Peter Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng,
> Ray Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1
> <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
>
> On 10/29/23 09:05, Yao, Jiewen wrote:
> > Those are great questions. I also would like to understand:
> >
> > 1) What is definition of "actively participating in their roles"?
>
> Here are the definitions of Maintainer and Reviewer, from
> "Maintainers.txt":
>
> M: Package Maintainer: Cc address for patches and questions. Responsible
> for reviewing and pushing package changes to source control.
> R: Package Reviewer: Cc address for patches and questions. Reviewers help
> maintainers review code, but don't have push access. A designated Package
> Reviewer is reasonably familiar with the Package (or some modules
> thereof), and/or provides testing or regression testing for the Package
> (or some modules thereof), in certain platforms and environments.
>
> > Is there any enforcement or just volunteer work?
>
> I see the Maintainer role as a service to the community, with some
> benefits granted in return. The "service" part should be clear. The
> benefit is that you are kept in the loop, and sometimes (when you must)
> you *can* say "no". (According to some seasoned reviewers, the one real
> power of a maintainer -- not to be abused! -- is "saying no".) A
> maintainer that's present helps set the focus, keep regressions out,
> gives advice when needed, and so on.
>
> Enforcement would be nice (haha), but it never works. You can't force
> people to help, especially if their dayjob instructions oppose their
> upstream community responsibilities. That's fine; in such cases my
> request is always: if you can't help, then at least don't get in the
> way, step down. Don't block people from doing their work by having them
> wait for your feedback.
>
> So volunteer work is fine, but as soon as the position grows "fangs" (=
> a capacity to make others wait), then it becomes a promise, a
> responsibility.
>
> >
> > 2) What is role and *responsibility* of Reviewer role? Is it
> > documented somewhere?
> > Per my observation, some assigned reviewers have never reviewed any
> > patch in history or provided valuable feedback. To me, reviewer role
> > seems more like a notification instead of really review something. Is
> > that our purpose?
>
> I'd say that's pretty close. A reviewer role is a request for keeping
> the reviewer in the loop. Maintainers tend to appreciate that, because a
> long-term reviewer may provide good insights, test results, and so on.
> Trust is super important; a maintainer may push a patch based solely on
> a reviewer's positive feedback, due to the latter's experience.
>
> > While Laszlo contributed a lots in Tianocore community, he is really a
> > good "reviewer", although he has no such title.
>
> Thanks for the acknowledgement, I appreciate it!
>
> I don't like to hoard titles. I'm sure titles are good for one's career,
> but I always see the *promise* (the responsibility) to the community,
> first and foremost, that a title encapsulates. It weighs heavily on me.
> I loathe disappointing people. For me, not to bear a title is better
> than to bear it and not to deliver on it / not to live up to it.
>
> Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110269): https://edk2.groups.io/g/devel/message/110269
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 15:42 ` Yao, Jiewen
@ 2023-10-29 16:01 ` James Bottomley
2023-10-29 16:25 ` Yao, Jiewen
0 siblings, 1 reply; 32+ messages in thread
From: James Bottomley @ 2023-10-29 16:01 UTC (permalink / raw)
To: Yao, Jiewen, Laszlo Ersek, devel@edk2.groups.io,
pedro.falcato@gmail.com, Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
On Sun, 2023-10-29 at 15:42 +0000, Yao, Jiewen wrote:
> > I'd say that's pretty close. A reviewer role is a request for
> > keeping
> > the reviewer in the loop.
>
> [Jiewen] I am disappointed on that.
> To me, that is NOT a real reviewer. See below description on what is
> "code review".
> https://google.github.io/eng-practices/review/
> https://about.gitlab.com/topics/version-control/what-is-code-review/
Well, that's what someone's view of what a patch review should consist
of, not what a reviewer's role in MAINTAINERS should be.
In general, you really don't want to force people to review patches,
because you'd like a reviewer to be familiar with the area and
comfortable with the patch. So are you saying that anyone listed as a
reviewer in a particular area should be capable of reviewing any patch?
and further that they should be expected to review every patch?
Because that's definitely not what the R role in the Linux Kernel would
mean.
I know that's not what happened to me in Confidential Computing,
because I had a very specific area around SEV and SEV-ES secret
injection and really had no familiarity at all with say the memory
acceptance patches.
> Our definition seems more like *a notification receiver*, instead of
> a real code reviewer. I would say, it is a very misleading
> definition.
Actually, I wouldn't, but then I'm more coming from a Linux Kernel
background. To us, the reviewer list is simply a list of people git
blame might not find who might have the expertise to review the patch
but on whom there would be no expectation that they would review the
patch.
James
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110270): https://edk2.groups.io/g/devel/message/110270
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 16:01 ` James Bottomley
@ 2023-10-29 16:25 ` Yao, Jiewen
2023-10-29 17:22 ` Michael D Kinney
2023-10-29 18:29 ` Pedro Falcato
0 siblings, 2 replies; 32+ messages in thread
From: Yao, Jiewen @ 2023-10-29 16:25 UTC (permalink / raw)
To: jejb@linux.ibm.com, Laszlo Ersek, devel@edk2.groups.io,
pedro.falcato@gmail.com, Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
OK. Maintainer should do code review. I have no doubt on that.
My confusion is about "reviewer" role. What is criteria and what is responsibility?
Are you saying that "reviewer" just means that someone raised the hand and said: "I want to be notified", and there is no expectation that he/she would review the patch?
I would like to understand more on how that works and what that means.
Would you please give a URL for the reviewer definition in Linux Kernel?
Thank you
Yao, Jiewen
> -----Original Message-----
> From: James Bottomley <jejb@linux.ibm.com>
> Sent: Monday, October 30, 2023 12:02 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>;
> devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>;
> Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>;
> De, Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter Grehan
> <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray Han Lim
> <ray.han.lim.ng@intel.com>; Stefan Berger <stefanb@linux.ibm.com>; Hou,
> Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
>
> On Sun, 2023-10-29 at 15:42 +0000, Yao, Jiewen wrote:
> > > I'd say that's pretty close. A reviewer role is a request for
> > > keeping
> > > the reviewer in the loop.
> >
> > [Jiewen] I am disappointed on that.
> > To me, that is NOT a real reviewer. See below description on what is
> > "code review".
> > https://google.github.io/eng-practices/review/
> > https://about.gitlab.com/topics/version-control/what-is-code-review/
>
> Well, that's what someone's view of what a patch review should consist
> of, not what a reviewer's role in MAINTAINERS should be.
>
> In general, you really don't want to force people to review patches,
> because you'd like a reviewer to be familiar with the area and
> comfortable with the patch. So are you saying that anyone listed as a
> reviewer in a particular area should be capable of reviewing any patch?
> and further that they should be expected to review every patch?
> Because that's definitely not what the R role in the Linux Kernel would
> mean.
>
> I know that's not what happened to me in Confidential Computing,
> because I had a very specific area around SEV and SEV-ES secret
> injection and really had no familiarity at all with say the memory
> acceptance patches.
>
> > Our definition seems more like *a notification receiver*, instead of
> > a real code reviewer. I would say, it is a very misleading
> > definition.
>
> Actually, I wouldn't, but then I'm more coming from a Linux Kernel
> background. To us, the reviewer list is simply a list of people git
> blame might not find who might have the expertise to review the patch
> but on whom there would be no expectation that they would review the
> patch.
>
> James
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110271): https://edk2.groups.io/g/devel/message/110271
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 16:25 ` Yao, Jiewen
@ 2023-10-29 17:22 ` Michael D Kinney
2023-10-30 2:40 ` Yao, Jiewen
2023-10-29 18:29 ` Pedro Falcato
1 sibling, 1 reply; 32+ messages in thread
From: Michael D Kinney @ 2023-10-29 17:22 UTC (permalink / raw)
To: Yao, Jiewen, jejb@linux.ibm.com, Laszlo Ersek,
devel@edk2.groups.io, pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1,
Kinney, Michael D
This is the Wiki page where TianoCore documents the TianoCore community
member roles.
https://github.com/tianocore/tianocore.github.io/wiki/TianoCore-Who-we-are
We can update/edit as needed to accurately reflect what all the Maintainers
and Reviewers agree are their roles and responsibilities as assigned in
Maintainers.txt.
Thanks,
Mike
> -----Original Message-----
> From: Yao, Jiewen <jiewen.yao@intel.com>
> Sent: Sunday, October 29, 2023 9:26 AM
> To: jejb@linux.ibm.com; Laszlo Ersek <lersek@redhat.com>;
> devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall
> <julien@xen.org>; Peter Grehan <grehan@freebsd.org>; Zhang, Qi1
> <qi1.zhang@intel.com>; Ng, Ray Han Lim <ray.han.lim.ng@intel.com>;
> Stefan Berger <stefanb@linux.ibm.com>; Hou, Wenxing
> <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
>
> OK. Maintainer should do code review. I have no doubt on that.
>
> My confusion is about "reviewer" role. What is criteria and what is
> responsibility?
>
> Are you saying that "reviewer" just means that someone raised the hand
> and said: "I want to be notified", and there is no expectation that
> he/she would review the patch?
>
> I would like to understand more on how that works and what that means.
> Would you please give a URL for the reviewer definition in Linux
> Kernel?
>
> Thank you
> Yao, Jiewen
>
>
>
> > -----Original Message-----
> > From: James Bottomley <jejb@linux.ibm.com>
> > Sent: Monday, October 30, 2023 12:02 AM
> > To: Yao, Jiewen <jiewen.yao@intel.com>; Laszlo Ersek
> <lersek@redhat.com>;
> > devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>;
> > Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> > <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> > Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>;
> > De, Debkumar <debkumar.de@intel.com>; Dong, Eric
> <eric.dong@intel.com>;
> > Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A
> <hao.a.wu@intel.com>;
> > Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> > <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
> Grehan
> > <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray Han
> Lim
> > <ray.han.lim.ng@intel.com>; Stefan Berger <stefanb@linux.ibm.com>;
> Hou,
> > Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> > Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based
> on active
> > community members
> >
> > On Sun, 2023-10-29 at 15:42 +0000, Yao, Jiewen wrote:
> > > > I'd say that's pretty close. A reviewer role is a request for
> > > > keeping
> > > > the reviewer in the loop.
> > >
> > > [Jiewen] I am disappointed on that.
> > > To me, that is NOT a real reviewer. See below description on what
> is
> > > "code review".
> > > https://google.github.io/eng-practices/review/
> > > https://about.gitlab.com/topics/version-control/what-is-code-
> review/
> >
> > Well, that's what someone's view of what a patch review should
> consist
> > of, not what a reviewer's role in MAINTAINERS should be.
> >
> > In general, you really don't want to force people to review patches,
> > because you'd like a reviewer to be familiar with the area and
> > comfortable with the patch. So are you saying that anyone listed as
> a
> > reviewer in a particular area should be capable of reviewing any
> patch?
> > and further that they should be expected to review every patch?
> > Because that's definitely not what the R role in the Linux Kernel
> would
> > mean.
> >
> > I know that's not what happened to me in Confidential Computing,
> > because I had a very specific area around SEV and SEV-ES secret
> > injection and really had no familiarity at all with say the memory
> > acceptance patches.
> >
> > > Our definition seems more like *a notification receiver*, instead
> of
> > > a real code reviewer. I would say, it is a very misleading
> > > definition.
> >
> > Actually, I wouldn't, but then I'm more coming from a Linux Kernel
> > background. To us, the reviewer list is simply a list of people git
> > blame might not find who might have the expertise to review the
> patch
> > but on whom there would be no expectation that they would review the
> > patch.
> >
> > James
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110272): https://edk2.groups.io/g/devel/message/110272
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 17:22 ` Michael D Kinney
@ 2023-10-30 2:40 ` Yao, Jiewen
2023-10-30 10:44 ` Laszlo Ersek
0 siblings, 1 reply; 32+ messages in thread
From: Yao, Jiewen @ 2023-10-30 2:40 UTC (permalink / raw)
To: Kinney, Michael D, jejb@linux.ibm.com, Laszlo Ersek,
devel@edk2.groups.io, pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
Thanks Mike. I am reading the WIKI page.
> and/or provides testing or regression testing for the Package (or some modules thereof), in certain platforms and environments.
[Jiewen] Are we expecting Reviewer to provide testing or regression testing for the package?
Is that what the reviewer *commits* to do?
For example, Maintainer may ask the reviewer to do some testing, right?
> Reviewer is responsible for timely responses on emails addressed to them (preferably less than calendar week).
[Jiewen]
Is that what the reviewer *commits* to do?
For example, Maintainer may ask the reviewer to provide feedback, right?
Those are more than just CCed.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Monday, October 30, 2023 1:23 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>; jejb@linux.ibm.com; Laszlo Ersek
> <lersek@redhat.com>; devel@edk2.groups.io; pedro.falcato@gmail.com
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>;
> Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>;
> De, Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter Grehan
> <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray Han Lim
> <ray.han.lim.ng@intel.com>; Stefan Berger <stefanb@linux.ibm.com>; Hou,
> Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>;
> Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
>
> This is the Wiki page where TianoCore documents the TianoCore community
> member roles.
>
> https://github.com/tianocore/tianocore.github.io/wiki/TianoCore-Who-we-are
>
> We can update/edit as needed to accurately reflect what all the Maintainers
> and Reviewers agree are their roles and responsibilities as assigned in
> Maintainers.txt.
>
> Thanks,
>
> Mike
>
>
> > -----Original Message-----
> > From: Yao, Jiewen <jiewen.yao@intel.com>
> > Sent: Sunday, October 29, 2023 9:26 AM
> > To: jejb@linux.ibm.com; Laszlo Ersek <lersek@redhat.com>;
> > devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> > <quic_llindhol@quicinc.com>; Warkentin, Andrei
> > <andrei.warkentin@intel.com>; West, Catharine
> > <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> > Schaefer <git@danielschaefer.me>; David Woodhouse
> > <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> > Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
> > Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
> > Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall
> > <julien@xen.org>; Peter Grehan <grehan@freebsd.org>; Zhang, Qi1
> > <qi1.zhang@intel.com>; Ng, Ray Han Lim <ray.han.lim.ng@intel.com>;
> > Stefan Berger <stefanb@linux.ibm.com>; Hou, Wenxing
> > <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> > Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> > active community members
> >
> > OK. Maintainer should do code review. I have no doubt on that.
> >
> > My confusion is about "reviewer" role. What is criteria and what is
> > responsibility?
> >
> > Are you saying that "reviewer" just means that someone raised the hand
> > and said: "I want to be notified", and there is no expectation that
> > he/she would review the patch?
> >
> > I would like to understand more on how that works and what that means.
> > Would you please give a URL for the reviewer definition in Linux
> > Kernel?
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> >
> > > -----Original Message-----
> > > From: James Bottomley <jejb@linux.ibm.com>
> > > Sent: Monday, October 30, 2023 12:02 AM
> > > To: Yao, Jiewen <jiewen.yao@intel.com>; Laszlo Ersek
> > <lersek@redhat.com>;
> > > devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> > <quic_llindhol@quicinc.com>;
> > > Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> > > <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> > > Schaefer <git@danielschaefer.me>; David Woodhouse
> > <dwmw2@infradead.org>;
> > > De, Debkumar <debkumar.de@intel.com>; Dong, Eric
> > <eric.dong@intel.com>;
> > > Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A
> > <hao.a.wu@intel.com>;
> > > Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> > > <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
> > Grehan
> > > <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray Han
> > Lim
> > > <ray.han.lim.ng@intel.com>; Stefan Berger <stefanb@linux.ibm.com>;
> > Hou,
> > > Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> > > Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based
> > on active
> > > community members
> > >
> > > On Sun, 2023-10-29 at 15:42 +0000, Yao, Jiewen wrote:
> > > > > I'd say that's pretty close. A reviewer role is a request for
> > > > > keeping
> > > > > the reviewer in the loop.
> > > >
> > > > [Jiewen] I am disappointed on that.
> > > > To me, that is NOT a real reviewer. See below description on what
> > is
> > > > "code review".
> > > > https://google.github.io/eng-practices/review/
> > > > https://about.gitlab.com/topics/version-control/what-is-code-
> > review/
> > >
> > > Well, that's what someone's view of what a patch review should
> > consist
> > > of, not what a reviewer's role in MAINTAINERS should be.
> > >
> > > In general, you really don't want to force people to review patches,
> > > because you'd like a reviewer to be familiar with the area and
> > > comfortable with the patch. So are you saying that anyone listed as
> > a
> > > reviewer in a particular area should be capable of reviewing any
> > patch?
> > > and further that they should be expected to review every patch?
> > > Because that's definitely not what the R role in the Linux Kernel
> > would
> > > mean.
> > >
> > > I know that's not what happened to me in Confidential Computing,
> > > because I had a very specific area around SEV and SEV-ES secret
> > > injection and really had no familiarity at all with say the memory
> > > acceptance patches.
> > >
> > > > Our definition seems more like *a notification receiver*, instead
> > of
> > > > a real code reviewer. I would say, it is a very misleading
> > > > definition.
> > >
> > > Actually, I wouldn't, but then I'm more coming from a Linux Kernel
> > > background. To us, the reviewer list is simply a list of people git
> > > blame might not find who might have the expertise to review the
> > patch
> > > but on whom there would be no expectation that they would review the
> > > patch.
> > >
> > > James
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110284): https://edk2.groups.io/g/devel/message/110284
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-30 2:40 ` Yao, Jiewen
@ 2023-10-30 10:44 ` Laszlo Ersek
0 siblings, 0 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-30 10:44 UTC (permalink / raw)
To: Yao, Jiewen, Kinney, Michael D, jejb@linux.ibm.com,
devel@edk2.groups.io, pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
On 10/30/23 03:40, Yao, Jiewen wrote:
> Thanks Mike. I am reading the WIKI page.
>
>
>> and/or provides testing or regression testing for the Package (or some modules thereof), in certain platforms and environments.
>
> [Jiewen] Are we expecting Reviewer to provide testing or regression testing for the package?
> Is that what the reviewer *commits* to do?
> For example, Maintainer may ask the reviewer to do some testing, right?
It depends on the reviewer's individual commitment.
First of all, the burden of testing / regression-testing, to a
reasonable extent [1], is on the submitter.
[1] In some cases, the submitter cannot test the code they modify in all
possible environments / circumstances. In such cases, the submitter
should test the change code wherever they can, as widely as they can,
and be upfront (in the commit message) about lacking coverage in other
environments they might be aware of. It is then fine for the maintainer
(or even reviewer) to ask others for further / wider testing, but trying
to saddle someone with that testing as an *obligation* will never fly.
That would only alienate people from contributing.
This was the primary reason for splitting Xen code as sharply as
possible from non-Xen code in both ArmVirtPkg and OvmfPkg. Xen and
QEMU/KVM are so different environments, with so distinct audiences, that
keeping code common was *worse* than duplicating and customizing code.
We could never *sufficiently* regression-test our changes for each
other. It was best to separate those areas of interest. Demanding that I
regression-test on Xen, or that Anthony or Julien regression-test on
QEMU/KVM, would have lead nowhere.
Second, the level of commitment varies. A reviewer may have a fleeting
interest in a module (just want to be in the loop), or else they may be
completely invested in it, and they might actually prefer being a
maintainer.
For example, I had seen many bad regressions in OVMF due to UefiCpuPkg
patches, thus, even thouogh I absolutely didn't welcome the additional
responsibility, I asked to be added as a Reviewer for UefiCpuPkg. With
that, I wanted to formalize my request to be CC'd on all UefiCpuPkg
patches, but I also committed to regression testing, and maybe even
reviewing, those patches. It worked out quite well, but of course I was
still selective in what I would review and test. If I could immediately
determine that the patch modified code in UefiCpuPkg that never ran on
(or wasn't even built into) OVMF, I would clearly state on the list that
I'd not review or test the patch, i.e., that nobody should wait for me.
>
>
>> Reviewer is responsible for timely responses on emails addressed to them (preferably less than calendar week).
>
> [Jiewen]
> Is that what the reviewer *commits* to do?
What I think we can expect a reviewer to *commit* to is to say
*something* reasonably quickly. The whole idea is to support others in
making a *decision*, in making progress. So the "something" the reviewer
says may well be:
- "this does not apply to the area I have expertise or interest in, so
please proceed with this patch without my feedback (testing or review or
opinion etc)"
- "I don't have time for this right now, so please go ahead; if it
breaks, we'll figure it out later" (the maintainer need not accept this,
and might want to block the patch independently for a bit longer, until
someone else provides the desired review or testing, but the reviewer is
still totally OK to say this)
- "please give me a few more days to review this set".
> For example, Maintainer may ask the reviewer to provide feedback, right?
IMO, the maintainer is welcome to request feedback, of course; that's
presumably why the reviewer wanted to be listed in Maintainers.txt in
the first place.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110305): https://edk2.groups.io/g/devel/message/110305
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 16:25 ` Yao, Jiewen
2023-10-29 17:22 ` Michael D Kinney
@ 2023-10-29 18:29 ` Pedro Falcato
1 sibling, 0 replies; 32+ messages in thread
From: Pedro Falcato @ 2023-10-29 18:29 UTC (permalink / raw)
To: devel, jiewen.yao
Cc: jejb@linux.ibm.com, Laszlo Ersek, Kinney, Michael D, Andrew Fish,
Leif Lindholm, Warkentin, Andrei, West, Catharine, Bi, Dandan,
Daniel Schaefer, David Woodhouse, De, Debkumar, Dong, Eric,
Jiang, Guomin, Wu, Hao A, Wang, Jian J, Justen, Jordan L,
Julien Grall, Peter Grehan, Zhang, Qi1, Ng, Ray Han Lim,
Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
On Sun, Oct 29, 2023 at 4:25 PM Yao, Jiewen <jiewen.yao@intel.com> wrote:
>
> OK. Maintainer should do code review. I have no doubt on that.
>
> My confusion is about "reviewer" role. What is criteria and what is responsibility?
>
> Are you saying that "reviewer" just means that someone raised the hand and said: "I want to be notified", and there is no expectation that he/she would review the patch?
>
> I would like to understand more on how that works and what that means.
The Linux development process, as I understand it (it may be a bit
imprecise, AFAIK lots of it isn't written):
Maintainers are the primary caretakers of the code. They'll review and
merge patches (in linux, they usually add their own Signed-off-by,
they don't do Reviewed-by). Sometimes, they'll post a patch on the
mailing list, and if there's no poor feedback, they just merge it to
their trees, unilaterally (for Linux, Linus usually pulls from
maintainer trees, and if he doesn't like something he *will* tell
you).
Reviewers are people that want to be CC'd and want to review patches,
but they're not expected to always do so. There's of course an
expectation that reviewers are relatively competent in the area
they're reviewing.
There's an expectation that you will help out and participate in code
review from time to time.
As an example:
SLAB ALLOCATOR
M: Christoph Lameter <cl@linux.com>
M: Pekka Enberg <penberg@kernel.org>
M: David Rientjes <rientjes@google.com>
M: Joonsoo Kim <iamjoonsoo.kim@lge.com>
M: Andrew Morton <akpm@linux-foundation.org>
M: Vlastimil Babka <vbabka@suse.cz>
R: Roman Gushchin <roman.gushchin@linux.dev>
R: Hyeonggon Yoo <42.hyeyoo@gmail.com>
L: linux-mm@kvack.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git
F: include/linux/sl?b*.h
F: mm/sl?b*
For a patch for mm/slab.c, you CC all M's and R's. Maintainers are the
one with the 'power' to merge it, and should give you feedback.
Reviewers sometimes help out (but are secondary in the patch review
role), but they cannot merge patches.
You only merge a patch if there's an understanding that most people
and stakeholders are ok with it; for example, you may want feedback
from people that are not M's and R's. If everyone is ok with your
patch, a maintainer will apply it (in this case, it's vbabka's tree so
he usually takes care of it), and it will eventually trickle up to
Linus (who manages the 'master' git tree) who gives the final seal of
approval when pulling changes.
For a smaller example, we can look at EFI, which has a sole maintainer
(Ard) and no reviewers; this is ok (EFI is a lot less central to the
kernel than SLAB, there are a lot less patches), but stakeholders in
the various changes should still test and review.
This is a nice rough description of the whole development process:
https://docs.kernel.org/process/2.Process.html
Note that EDK2 is considerably smaller than the kernel in scope and
patch volume, so it probably doesn't make much sense to be as
distributed as Linux.
PS: It's worth noting that the Linux equivalent to GetMaintainers.py
takes into account the git blame of the files you're touching, terms
you mention in the commit message; that is, it will automatically pick
up people that have touched the code before or are responsible for
features you're interacting with.
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110273): https://edk2.groups.io/g/devel/message/110273
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 2:16 ` Pedro Falcato
2023-10-29 8:05 ` Yao, Jiewen
@ 2023-10-29 13:30 ` Laszlo Ersek
2023-10-29 19:01 ` Pedro Falcato
2023-10-30 2:54 ` Yao, Jiewen
2023-10-30 7:38 ` Ng, Ray Han Lim
2 siblings, 2 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-29 13:30 UTC (permalink / raw)
To: devel, pedro.falcato, michael.d.kinney
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
On 10/29/23 03:16, Pedro Falcato wrote:
> On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
> <michael.d.kinney@intel.com> 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 <laura.chan@intel.com>
>> * 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 <sami.mujawar@arm.com> [samimujawar]
>> RISCV64
>> F: */RiscV64/
>> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
>> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>>
>> LOONGARCH64
>> F: */LoongArch64/
>> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
>> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
>> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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 <jiewen.yao@intel.com> [jyao1]
>> M: Yi Li <yi1.li@intel.com> [liyi77]
>> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
>> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
>> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
>>
>> DynamicTablesPkg
>> F: DynamicTablesPkg/
>> @@ -202,7 +191,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
>> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
>> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
>> M: Abner Chang <abner.chang@amd.com> [changab]
>> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>>
>> EmulatorPkg
>> F: EmulatorPkg/
>> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
>> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
>> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
>> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
>> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
>>
>> IntelFsp2Pkg
>> @@ -237,7 +224,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
>> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
>> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
>> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
>> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
>> R: Star Zeng <star.zeng@intel.com> [lzeng14]
>> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
>> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
>> @@ -258,7 +244,6 @@ R: Susovan Mohapatra <susovan.mohapatra@intel.com> [susovanmohapatra]
>> MdeModulePkg
>> F: MdeModulePkg/
>> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
>> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>> M: Liming Gao <gaoliming@byosoft.com.cn> [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 <zhiguang.liu@intel.com> [LiuZhiguang001]
>> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
>> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
>> -R: Eric Dong <eric.dong@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
>> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
>> R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> Device and bus related code is down to one reviewer.
>
>>
>> MdeModulePkg: Disk modules
>> F: MdeModulePkg/Universal/Disk/
>> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
>> R: Ray Ni <ray.ni@intel.com> [niruiyu]
>> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>>
>> @@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
>> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
>> F: MdeModulePkg/Universal/Esrt*/
>> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>> -R: Guomin Jiang <guomin.jiang@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
>> -R: Eric Dong <eric.dong@intel.com> [ydong10]
>
> One reviewer
>>
>> MdeModulePkg: Management Mode (MM, SMM) modules
>> F: MdeModulePkg/*Smi*/
>> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
>>
>> MdeModulePkg: Pei Core
>> F: MdeModulePkg/Core/Pei/
>> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
>> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>> -R: Debkumar De <debkumar.de@intel.com> [dde01]
>> -R: Catharine West <catharine.west@intel.com> [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 <hao.a.wu@intel.com> [hwu25]
>> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <gua.guo@intel.com> [gguo11837463]
>> M: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
>> -R: Chan Laura <laura.chan@intel.com> [lauracha]
>> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
>>
>> MdeModulePkg: USB Network modules
>> @@ -497,7 +463,6 @@ F: OvmfPkg/
>> W: http://www.tianocore.org/ovmf/
>> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
>> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
>> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
>> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
>> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
>> R: Corvin Köhne <corvink@freebsd.org> [corvink]
>>
>> OvmfPkg: cloudhv-related modules
>> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
>> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
>> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>>
>> -OvmfPkg: CSM modules
>> -F: OvmfPkg/Csm/
>> -R: David Woodhouse <dwmw2@infradead.org> [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 <erdemaktas@google.com> [ruleof2]
>> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
>> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
>> R: Min Xu <min.m.xu@intel.com> [mxu9]
>> R: Tom Lendacky <thomas.lendacky@amd.com> [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 <marcandre.lureau@redhat.com> [elmarco]
>> -R: Stefan Berger <stefanb@linux.ibm.com> [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 <anthony.perard@citrix.com> [tperard]
>> -R: Julien Grall <julien@xen.org> [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 <jiewen.yao@intel.com> [jyao1]
>> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>>
>> SecurityPkg: Secure boot related modules
>> F: SecurityPkg/Library/DxeImageVerificationLib/
>> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
>>
>> SecurityPkg: Tcg related modules
>> F: SecurityPkg/Tcg/
>> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
>> R: Rahul Kumar <rahul1.kumar@intel.com> [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 <zhichao.gao@intel.com> [ZhichaoGao]
>> SignedCapsulePkg
>> F: SignedCapsulePkg/
>> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
>> -M: Jian J Wang <jian.j.wang@intel.com> [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 <hao.a.wu@intel.com> [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 <ray.ni@intel.com> [niruiyu]
>> UefiCpuPkg
>> F: UefiCpuPkg/
>> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
>> -M: Eric Dong <eric.dong@intel.com> [ydong10]
>> M: Ray Ni <ray.ni@intel.com> [niruiyu]
>> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
>> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>> UefiCpuPkg: Sec related modules
>> F: UefiCpuPkg/SecCore/
>> F: UefiCpuPkg/ResetVector/
>> -R: Debkumar De <debkumar.de@intel.com> [dde01]
>> R: Catharine West <catharine.west@intel.com> [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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 13:30 ` Laszlo Ersek
@ 2023-10-29 19:01 ` Pedro Falcato
2023-10-30 11:25 ` Laszlo Ersek
2023-10-30 2:54 ` Yao, Jiewen
1 sibling, 1 reply; 32+ messages in thread
From: Pedro Falcato @ 2023-10-29 19:01 UTC (permalink / raw)
To: devel, lersek
Cc: michael.d.kinney, 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
On Sun, Oct 29, 2023 at 1:30 PM Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 10/29/23 03:16, Pedro Falcato wrote:
> >> 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 <sami.mujawar@arm.com> [samimujawar]
> >> RISCV64
> >> F: */RiscV64/
> >> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> >> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> >> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
> >>
> >> LOONGARCH64
> >> F: */LoongArch64/
> >> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> >> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> >> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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.
I agree with this solution, but I do think there should be a "time
limit" for orphaned code. You don't want to keep orphaned code for too
long, this is not a practice we should support (which may lead to
corporate code dumps where corps just dump a bunch of patches on the
mailing list, fire and forget, and they're still "supported").
>
> >
> >> 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 <jiewen.yao@intel.com> [jyao1]
> >> M: Yi Li <yi1.li@intel.com> [liyi77]
> >> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> >> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> >> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
> >>
> >> DynamicTablesPkg
> >> F: DynamicTablesPkg/
> >> @@ -202,7 +191,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> >> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> >> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> >> M: Abner Chang <abner.chang@amd.com> [changab]
> >> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> >>
> >> EmulatorPkg
> >> F: EmulatorPkg/
> >> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> >> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> >> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> >> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
> >>
> >> IntelFsp2Pkg
> >> @@ -237,7 +224,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> >> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> >> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> >> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> >> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> >> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> >> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> >> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> >> @@ -258,7 +244,6 @@ R: Susovan Mohapatra <susovan.mohapatra@intel.com> [susovanmohapatra]
> >> MdeModulePkg
> >> F: MdeModulePkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >> M: Liming Gao <gaoliming@byosoft.com.cn> [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".
I understand your idea. I do, however, see it going in 2 different ways:
1) This pressures maintainers/corporations to be faster at reviewing
patches, keeping a smooth flow of careful, reviewed patches. Things
continue to work smoothly.
2) Maintainers keep being unresponsive, patches get "auto merged" and
people need to deal with any ensuing breakage. Things /may/ regularly
break.
IMO, this solution does not solve anything. If maintainers are short
on time (or simply spread too thin), they will still be short on time
unless corps give them more time for FOSS work. This just adds a fear
factor ("Complete shite may be automerged if you don't have people on
it!!").
And frankly, I find it hard to find a solution for this problem, since
the vast majority of the firmware product sits *outside* of the
open-source repos, sometimes with gnarly forks in the way. How do we
convince more people to engage out in the open?
>
> 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.)
Nice, thanks! I'll defer making any promises on my end, but I may end
up helping out (as I sometimes do, anyway).
>
> >>
> >> MdeModulePkg: ACPI modules
> >> @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]
> >> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> >> -R: Eric Dong <eric.dong@intel.com> [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).
>
I know Intel has abandoned S3 over the (equally cursed!) S0ix/S2idle.
I don't know how the situation is on AMD/ARM. Do QEMU/libvirt/whatever
use S3 for anything useful? I know they do roughly support it.
> >> @@ -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 <dandan.bi@intel.com> [dandanbi]
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [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.
I really appreciate your involvement in EDK2, but if the alternative
for "Liming 'owns' half of EDK2.git" is "Liming AND Laszlo 'own' half
of EDK2.git", I don't see how this can be sustainable without
maintainer burnout :/
> >> -OvmfPkg: CSM modules
> >> -F: OvmfPkg/Csm/
> >> -R: David Woodhouse <dwmw2@infradead.org> [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.
How is CSM looking in the virtualization space? Individual QEMU users
probably wouldn't miss it much (since SeaBIOS exists and even is the
default), but I don't know what you folks are using for firmware.
>
> >> -
> >> 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 <erdemaktas@google.com> [ruleof2]
> >> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> >> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> >> R: Min Xu <min.m.xu@intel.com> [mxu9]
> >> R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
>
> It's good for the project that CoCo has several reviewers still.
Yes, OVMF in general still seems quite well staffed (probably because
the development is done upstream!)
> >> ShellPkg
> >> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> >> SignedCapsulePkg
> >> F: SignedCapsulePkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >
> > Unmaintained
>
> Probably best to mark it as orphaned then!
Wasn't Intel big on capsules?
> >> SourceLevelDebugPkg
> >> F: SourceLevelDebugPkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
> >> -M: Hao A Wu <hao.a.wu@intel.com> [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 <ray.ni@intel.com> [niruiyu]
> >> UefiCpuPkg
> >> F: UefiCpuPkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> >> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> >> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> >> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> >> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >> UefiCpuPkg: Sec related modules
> >> F: UefiCpuPkg/SecCore/
> >> F: UefiCpuPkg/ResetVector/
> >> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> >> R: Catharine West <catharine.west@intel.com> [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'!" :)
Heh :) FWIW, when we tried to use it for QemuOpenBoardPkg we found
multiple problems and instantly had to write our own SEC (although it
may have been PEBKAC, I don't know if this SecCore is used in real
platforms).
>
> >
> > 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!
Overengineered and underreviewed? Yikes...
> > 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.
Agreed.
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110274): https://edk2.groups.io/g/devel/message/110274
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 19:01 ` Pedro Falcato
@ 2023-10-30 11:25 ` Laszlo Ersek
0 siblings, 0 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-30 11:25 UTC (permalink / raw)
To: Pedro Falcato, devel
Cc: michael.d.kinney, 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
On 10/29/23 20:01, Pedro Falcato wrote:
> On Sun, Oct 29, 2023 at 1:30 PM Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> On 10/29/23 03:16, Pedro Falcato wrote:
>>>> 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 <sami.mujawar@arm.com> [samimujawar]
>>>> RISCV64
>>>> F: */RiscV64/
>>>> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
>>>> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>>>> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>>>>
>>>> LOONGARCH64
>>>> F: */LoongArch64/
>>>> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
>>>> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
>>>> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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.
>
> I agree with this solution, but I do think there should be a "time
> limit" for orphaned code. You don't want to keep orphaned code for too
> long, this is not a practice we should support (which may lead to
> corporate code dumps where corps just dump a bunch of patches on the
> mailing list, fire and forget, and they're still "supported").
Very difficult question; there could be end-users relying on the feature
still, without anyone shouldering the maintenance costs :( I certainly
see your point, I just can't either agree *or* disagree with it!
(I recently cleaned up even *build* breakages in edk2-platforms; I also
found libraries that were not used *at all* by in-tree platforms. Those
obviously come from ancient corporate code-drops, and nobody must have
built them very recently, but if we remove them, we could still
ultimately harm end-users.)
[...]
>> 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".
>
> I understand your idea. I do, however, see it going in 2 different ways:
> 1) This pressures maintainers/corporations to be faster at reviewing
> patches, keeping a smooth flow of careful, reviewed patches. Things
> continue to work smoothly.
> 2) Maintainers keep being unresponsive, patches get "auto merged" and
> people need to deal with any ensuing breakage. Things /may/ regularly
> break.
You are too polite; it's quite likely that things *will* break :)
> IMO, this solution does not solve anything. If maintainers are short
> on time (or simply spread too thin), they will still be short on time
> unless corps give them more time for FOSS work. This just adds a fear
> factor ("Complete shite may be automerged if you don't have people on
> it!!").
The alternative is stasis, as I wrote above. Everything grinds to a
halt, and people can't proceed with careful, justified work either.
The true solution is for the orgs behind the maintainers to invest more
resources into maintenance. If that's not happening (and I don't see it
happening), then you can only choose between stasis and chaos.
Presently, I'm trending towards chaos. Here's why:
- because it lets *me* do my work at least,
- it lets me assist with review & testing for such subsystems that I may
not be *directly* interested in.
Stasis means my own work is blocked, and that I cannot help others
progress with their work either (if my review or testing is ignored by a
maintainer, then the submitter isn't any better off).
... I think my stance on this may have changed in the last two years.
During that time, I focused on the libguestfs mailing list. Very small
community, mostly based on trust, fast moving, much more relaxed towards
reviews (especially iterated reviews). The same circumstances don't
apply to edk2-devel 1-to-1 of course, but it still made the faster,
lighter pace of development attractive to me.
Obviously I'm still a fan of a super-strict process as well, but *then*
the entire community must put in the resources! And that's not happening
on edk2.
> And frankly, I find it hard to find a solution for this problem, since
> the vast majority of the firmware product sits *outside* of the
> open-source repos, sometimes with gnarly forks in the way. How do we
> convince more people to engage out in the open?
We can't.
They don't see a return on their investment -- and their opinion is
likely supported by hard numbers.
(I suspect that a heavy-weight, slow review process is a repelling factor.)
[...]
>> 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).
>>
>
> I know Intel has abandoned S3 over the (equally cursed!) S0ix/S2idle.
Huh, that's news to me. Thanks for the heads-up!
> I don't know how the situation is on AMD/ARM. Do QEMU/libvirt/whatever
> use S3 for anything useful? I know they do roughly support it.
Putting a guest to S3 sleep is good for two purposes:
- It's better than just pausing the guest, because the guest will be
aware that time stops / there's going to be a time discontinuity.
- If you want to put the *host* to S3 sleep, while guests exist, that's
a can of worms, and if you put the guests to S3 sleep *first*, it
becomes a lesser can of worms. :)
Regarding "roughly" -- as long as guest kernel drivers participate, S3
should be stable, I don't perceive anything to be "rough" about it.
(Note that "guest kernel drivers participate" is a serious condition --
it's the reason why RHEL does *not* support S3 for guests :))
>>>> @@ -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 <dandan.bi@intel.com> [dandanbi]
>>>> R: Liming Gao <gaoliming@byosoft.com.cn> [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.
>
> I really appreciate your involvement in EDK2, but if the alternative
> for "Liming 'owns' half of EDK2.git" is "Liming AND Laszlo 'own' half
> of EDK2.git", I don't see how this can be sustainable without
> maintainer burnout :/
*ownership* is not sustainable, indeed.
But what can we do? If a reviewer won't (or can't) continue in their
original role, we can't force them. So we either redistribute, or just
let go of the strict review requirement (or a mixture of both).
NB, one special case of "letting go of the strict review requirement" is
*forking* edk2. Basically switching from an "upstream first" to an
"upstream second" (or well, "upstream never") approach.
AIUI, Project Mu is "upstream second". Early Linaro trees were (again,
AIUI) "upstream second". The "gnarly forks" you mention are "upstream
never".
Easing up on the review requirements could be a means to preserve the
centrality / primacy (?) of edk2. We'd not "insist" on reviews, and
correspondingly, we'd not "own" subsystems. Dunno, just brainstorming.
[...]
> How is CSM looking in the virtualization space? Individual QEMU users
> probably wouldn't miss it much (since SeaBIOS exists and even is the
> default), but I don't know what you folks are using for firmware.
CSM is incredibly complicated and effectively undebuggable. I had had
some serious struggles with it, years ago, back when KVM's emulation for
real mode was rougher around the edges. Those experiences scarred me
enough that I upfront told everyone on my team that I would never ever
consider supporting CSM in any RHEL build of OVMF.
Then, in a virtual machine (considering the hardware description, such
as the libvirt domain XML -- not meaning an already installed guest
OS!), it's really simple to pick your firmware (this was a great point
that Gerd made originally). So if you want BIOS, just pick SeaBIOS and
be done with it.
David Woodhouse had a very special (arguably: "obscure") use case in
AWS, if I remember correctly. That was the sole reason why we had
migrated CSM from Intel(Framework)ModulePkg to OVMF:
https://bugzilla.tianocore.org/show_bug.cgi?id=1811
But now, upon the removal of David's "R" entry, I figure there's just
nobody left who cares.
[...]
>>>> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>>>> SignedCapsulePkg
>>>> F: SignedCapsulePkg/
>>>> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
>>>> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>>>
>>> Unmaintained
>>
>> Probably best to mark it as orphaned then!
>
> Wasn't Intel big on capsules?
This is another instance of the same discussion on orphaned modules :)
I can imagine that SignedCapsulePkg is so stable / finished that it
needs no dedicated maintainers. That doesn't mean it's fallen out of use.
If you think about it, stable software that never gets new features,
only the occasional bugfix, is the best software for *some* users.
(For example, I know I want *exactly that*, of my desktop environment!)
[...]
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110310): https://edk2.groups.io/g/devel/message/110310
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 13:30 ` Laszlo Ersek
2023-10-29 19:01 ` Pedro Falcato
@ 2023-10-30 2:54 ` Yao, Jiewen
2023-10-30 5:31 ` Michael D Kinney
1 sibling, 1 reply; 32+ messages in thread
From: Yao, Jiewen @ 2023-10-30 2:54 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, pedro.falcato@gmail.com,
Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
> 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.
[Jiewen] Yes. I agree this approach.
A reasonable timeout seems enough to allow people to think and feedback.
Also, I would like to propose another the contribution condition relax.
Currently, our agreed condition to merge is:
1) Reviewed-by from Maintainer.
2) Acked-by from Maintainer + Reviewed-by from Reviewer
I propose to change the second condition:
2) Acked-by from Maintainer + Reviewed-by from anyone who can be trusted by the maintainer.
That is based upon the current situation - anyone can be a reviewer just because they want to be CCed and has no expectation to review the code.
Restricting R-B from a reviewer does not make sense to me.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Sunday, October 29, 2023 9:30 PM
> To: devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>;
> Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>;
> De, Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> James Bottomley <jejb@linux.ibm.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>;
> Peter Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng,
> Ray Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1
> <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
>
> On 10/29/23 03:16, Pedro Falcato wrote:
> > On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
> > <michael.d.kinney@intel.com> 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 <laura.chan@intel.com>
> >> * 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 <sami.mujawar@arm.com>
> [samimujawar]
> >> RISCV64
> >> F: */RiscV64/
> >> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> >> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> >> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
> >>
> >> LOONGARCH64
> >> F: */LoongArch64/
> >> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> [leiflindholm]
> >> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> >> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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 <jiewen.yao@intel.com> [jyao1]
> >> M: Yi Li <yi1.li@intel.com> [liyi77]
> >> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> >> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> >> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
> >>
> >> DynamicTablesPkg
> >> F: DynamicTablesPkg/
> >> @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> >> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> >> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> >> M: Abner Chang <abner.chang@amd.com> [changab]
> >> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> >>
> >> EmulatorPkg
> >> F: EmulatorPkg/
> >> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> >> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> >> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> >> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
> >>
> >> IntelFsp2Pkg
> >> @@ -237,7 +224,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> >> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> >> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> >> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> >> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> >> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> >> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> >> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> >> @@ -258,7 +244,6 @@ R: Susovan Mohapatra
> <susovan.mohapatra@intel.com> [susovanmohapatra]
> >> MdeModulePkg
> >> F: MdeModulePkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >> M: Liming Gao <gaoliming@byosoft.com.cn> [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 <zhiguang.liu@intel.com>
> [LiuZhiguang001]
> >> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> >> -R: Eric Dong <eric.dong@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> >> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> >
> > Device and bus related code is down to one reviewer.
> >
> >>
> >> MdeModulePkg: Disk modules
> >> F: MdeModulePkg/Universal/Disk/
> >> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> >> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> >> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> >>
> >> @@ -366,7 +339,6 @@ F:
> MdeModulePkg/Library/DisplayUpdateProgressLib*/
> >> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> >> F: MdeModulePkg/Universal/Esrt*/
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >> -R: Guomin Jiang <guomin.jiang@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> >> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> >
> > One reviewer
> >>
> >> MdeModulePkg: Management Mode (MM, SMM) modules
> >> F: MdeModulePkg/*Smi*/
> >> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
> >>
> >> MdeModulePkg: Pei Core
> >> F: MdeModulePkg/Core/Pei/
> >> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> >> -R: Catharine West <catharine.west@intel.com> [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 <hao.a.wu@intel.com> [hwu25]
> >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <gua.guo@intel.com> [gguo11837463]
> >> M: Prakashan Krishnadas Veliyathuparambil
> <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> >> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> >> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
> >>
> >> MdeModulePkg: USB Network modules
> >> @@ -497,7 +463,6 @@ F: OvmfPkg/
> >> W: http://www.tianocore.org/ovmf/
> >> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> >> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> >> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> >> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> >> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> >> R: Corvin Köhne <corvink@freebsd.org> [corvink]
> >>
> >> OvmfPkg: cloudhv-related modules
> >> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> >> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> >> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >>
> >> -OvmfPkg: CSM modules
> >> -F: OvmfPkg/Csm/
> >> -R: David Woodhouse <dwmw2@infradead.org> [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 <erdemaktas@google.com> [ruleof2]
> >> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> >> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> >> R: Min Xu <min.m.xu@intel.com> [mxu9]
> >> R: Tom Lendacky <thomas.lendacky@amd.com> [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 <marcandre.lureau@redhat.com> [elmarco]
> >> -R: Stefan Berger <stefanb@linux.ibm.com> [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 <anthony.perard@citrix.com> [tperard]
> >> -R: Julien Grall <julien@xen.org> [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 <jiewen.yao@intel.com> [jyao1]
> >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >>
> >> SecurityPkg: Secure boot related modules
> >> F: SecurityPkg/Library/DxeImageVerificationLib/
> >> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
> >>
> >> SecurityPkg: Tcg related modules
> >> F: SecurityPkg/Tcg/
> >> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> >> R: Rahul Kumar <rahul1.kumar@intel.com> [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 <zhichao.gao@intel.com>
> [ZhichaoGao]
> >> SignedCapsulePkg
> >> F: SignedCapsulePkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> >> -M: Jian J Wang <jian.j.wang@intel.com> [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 <hao.a.wu@intel.com> [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 <ray.ni@intel.com> [niruiyu]
> >> UefiCpuPkg
> >> F: UefiCpuPkg/
> >> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> >> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> >> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> >> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> >> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >> UefiCpuPkg: Sec related modules
> >> F: UefiCpuPkg/SecCore/
> >> F: UefiCpuPkg/ResetVector/
> >> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> >> R: Catharine West <catharine.west@intel.com> [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 (#110285): https://edk2.groups.io/g/devel/message/110285
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-30 2:54 ` Yao, Jiewen
@ 2023-10-30 5:31 ` Michael D Kinney
2023-10-30 11:29 ` Laszlo Ersek
0 siblings, 1 reply; 32+ messages in thread
From: Michael D Kinney @ 2023-10-30 5:31 UTC (permalink / raw)
To: Yao, Jiewen, devel@edk2.groups.io, lersek@redhat.com,
pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1, Kinney, Michael D
There is a very good discussion here on the roles and responsibility
and potential suggestions for changes to the Wiki page that document
those roles and responsibilities.
May I suggest that someone start a new thread that discusses
the proposed changes to the Wiki page and leave this thread for the
review of the changes to Maintainers.txt?
Thanks,
Mike
> -----Original Message-----
> From: Yao, Jiewen <jiewen.yao@intel.com>
> Sent: Sunday, October 29, 2023 7:54 PM
> To: devel@edk2.groups.io; lersek@redhat.com; pedro.falcato@gmail.com;
> Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
> Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray
> Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu,
> Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
>
> > 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.
>
> [Jiewen] Yes. I agree this approach.
> A reasonable timeout seems enough to allow people to think and
> feedback.
>
>
>
> Also, I would like to propose another the contribution condition
> relax.
>
> Currently, our agreed condition to merge is:
> 1) Reviewed-by from Maintainer.
> 2) Acked-by from Maintainer + Reviewed-by from Reviewer
>
> I propose to change the second condition:
> 2) Acked-by from Maintainer + Reviewed-by from anyone who can be
> trusted by the maintainer.
>
>
> That is based upon the current situation - anyone can be a reviewer
> just because they want to be CCed and has no expectation to review the
> code.
> Restricting R-B from a reviewer does not make sense to me.
>
> Thank you
> Yao, Jiewen
>
>
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Laszlo Ersek
> > Sent: Sunday, October 29, 2023 9:30 PM
> > To: devel@edk2.groups.io; pedro.falcato@gmail.com; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>;
> > Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine
> > <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> > Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>;
> > De, Debkumar <debkumar.de@intel.com>; Dong, Eric
> <eric.dong@intel.com>;
> > Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A
> <hao.a.wu@intel.com>;
> > James Bottomley <jejb@linux.ibm.com>; Wang, Jian J
> <jian.j.wang@intel.com>;
> > Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall
> <julien@xen.org>;
> > Peter Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>;
> Ng,
> > Ray Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> > <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu,
> Xiaoyu1
> > <xiaoyu1.lu@intel.com>
> > Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based
> on active
> > community members
> >
> > On 10/29/23 03:16, Pedro Falcato wrote:
> > > On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
> > > <michael.d.kinney@intel.com> 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 <laura.chan@intel.com>
> > >> * 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 <sami.mujawar@arm.com>
> > [samimujawar]
> > >> RISCV64
> > >> F: */RiscV64/
> > >> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> > >> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> > >> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
> > >>
> > >> LOONGARCH64
> > >> F: */LoongArch64/
> > >> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> > [leiflindholm]
> > >> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> > >> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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 <jiewen.yao@intel.com> [jyao1]
> > >> M: Yi Li <yi1.li@intel.com> [liyi77]
> > >> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> > >> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> > >> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
> > >>
> > >> DynamicTablesPkg
> > >> F: DynamicTablesPkg/
> > >> @@ -202,7 +191,6 @@ W:
> > https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> > >> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> > >> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> > >> M: Abner Chang <abner.chang@amd.com> [changab]
> > >> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> > >>
> > >> EmulatorPkg
> > >> F: EmulatorPkg/
> > >> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> > >> W:
> https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> > >> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > >> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> > >> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> > >> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
> > >>
> > >> IntelFsp2Pkg
> > >> @@ -237,7 +224,6 @@ W:
> > https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> > >> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> > >> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-
> desimone]
> > >> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> > >> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> > >> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> > >> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> > >> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> > >> @@ -258,7 +244,6 @@ R: Susovan Mohapatra
> > <susovan.mohapatra@intel.com> [susovanmohapatra]
> > >> MdeModulePkg
> > >> F: MdeModulePkg/
> > >> W:
> https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> > >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> > >> M: Liming Gao <gaoliming@byosoft.com.cn> [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 <zhiguang.liu@intel.com>
> > [LiuZhiguang001]
> > >> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> > >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> > >> -R: Eric Dong <eric.dong@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> > >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> > >> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> > >
> > > Device and bus related code is down to one reviewer.
> > >
> > >>
> > >> MdeModulePkg: Disk modules
> > >> F: MdeModulePkg/Universal/Disk/
> > >> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> > >> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> > >> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> > >>
> > >> @@ -366,7 +339,6 @@ F:
> > MdeModulePkg/Library/DisplayUpdateProgressLib*/
> > >> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> > >> F: MdeModulePkg/Universal/Esrt*/
> > >> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > >> -R: Guomin Jiang <guomin.jiang@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> > >> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> > >
> > > One reviewer
> > >>
> > >> MdeModulePkg: Management Mode (MM, SMM) modules
> > >> F: MdeModulePkg/*Smi*/
> > >> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
> > >>
> > >> MdeModulePkg: Pei Core
> > >> F: MdeModulePkg/Core/Pei/
> > >> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> > >> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > >> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> > >> -R: Catharine West <catharine.west@intel.com> [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 <hao.a.wu@intel.com> [hwu25]
> > >> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <gua.guo@intel.com> [gguo11837463]
> > >> M: Prakashan Krishnadas Veliyathuparambil
> > <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> > >> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> > >> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
> > >>
> > >> MdeModulePkg: USB Network modules
> > >> @@ -497,7 +463,6 @@ F: OvmfPkg/
> > >> W: http://www.tianocore.org/ovmf/
> > >> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> > >> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> > >> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> > >> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> > >> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> > >> R: Corvin Köhne <corvink@freebsd.org> [corvink]
> > >>
> > >> OvmfPkg: cloudhv-related modules
> > >> @@ -528,10 +492,6 @@ F:
> OvmfPkg/Include/IndustryStandard/Microvm.h
> > >> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> > >> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > >>
> > >> -OvmfPkg: CSM modules
> > >> -F: OvmfPkg/Csm/
> > >> -R: David Woodhouse <dwmw2@infradead.org> [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 <erdemaktas@google.com> [ruleof2]
> > >> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> > >> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> > >> R: Min Xu <min.m.xu@intel.com> [mxu9]
> > >> R: Tom Lendacky <thomas.lendacky@amd.com> [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 <marcandre.lureau@redhat.com> [elmarco]
> > >> -R: Stefan Berger <stefanb@linux.ibm.com> [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 <anthony.perard@citrix.com> [tperard]
> > >> -R: Julien Grall <julien@xen.org> [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 <jiewen.yao@intel.com> [jyao1]
> > >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> > >>
> > >> SecurityPkg: Secure boot related modules
> > >> F: SecurityPkg/Library/DxeImageVerificationLib/
> > >> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
> > >>
> > >> SecurityPkg: Tcg related modules
> > >> F: SecurityPkg/Tcg/
> > >> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> > >> R: Rahul Kumar <rahul1.kumar@intel.com> [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 <zhichao.gao@intel.com>
> > [ZhichaoGao]
> > >> SignedCapsulePkg
> > >> F: SignedCapsulePkg/
> > >> W:
> https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> > >> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> > >
> > > Unmaintained
> >
> > Probably best to mark it as orphaned then!
> >
> > >
> > >>
> > >> SourceLevelDebugPkg
> > >> F: SourceLevelDebugPkg/
> > >> W:
> >
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebug
> Pkg
> > >> -M: Hao A Wu <hao.a.wu@intel.com> [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 <ray.ni@intel.com> [niruiyu]
> > >> UefiCpuPkg
> > >> F: UefiCpuPkg/
> > >> W:
> https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> > >> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> > >> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> > >> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> > >> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > >> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > >> UefiCpuPkg: Sec related modules
> > >> F: UefiCpuPkg/SecCore/
> > >> F: UefiCpuPkg/ResetVector/
> > >> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> > >> R: Catharine West <catharine.west@intel.com> [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 (#110288): https://edk2.groups.io/g/devel/message/110288
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-30 5:31 ` Michael D Kinney
@ 2023-10-30 11:29 ` Laszlo Ersek
2023-10-30 22:18 ` Michael D Kinney
0 siblings, 1 reply; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-30 11:29 UTC (permalink / raw)
To: Kinney, Michael D, Yao, Jiewen, devel@edk2.groups.io,
pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
On 10/30/23 06:31, Kinney, Michael D wrote:
> There is a very good discussion here on the roles and responsibility
> and potential suggestions for changes to the Wiki page that document
> those roles and responsibilities.
>
> May I suggest that someone start a new thread that discusses
> the proposed changes to the Wiki page and leave this thread for the
> review of the changes to Maintainers.txt?
These are connected topics, but yes, back to "Maintainers.txt" -- do you
feel that "S: Orphan" sections are acceptable in general? They're a
first (AFAICT) for edk2's "Maintainers.txt"; we've always had the
mechanism documented (since the creation of "Maintainers.txt", or so),
but we never seem to have put it to use.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110311): https://edk2.groups.io/g/devel/message/110311
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-30 11:29 ` Laszlo Ersek
@ 2023-10-30 22:18 ` Michael D Kinney
2023-10-31 10:16 ` Laszlo Ersek
0 siblings, 1 reply; 32+ messages in thread
From: Michael D Kinney @ 2023-10-30 22:18 UTC (permalink / raw)
To: Laszlo Ersek, Yao, Jiewen, devel@edk2.groups.io,
pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1, Kinney, Michael D
Hi Laszlo,
I do not support orphaned categories and that option should be
removed from Maintainer.txt. One of the motivations to get
Maintainers.txt updated is to work on the set of tasks related to
using GitHub PRs for code review. If a component is orphaned,
then nobody would be assigned to a PR in that area and the PR
would be stuck and would eventually be deleted for no activity.
A terrible experience for a submitter.
If there is a feature for which there is no longer any support,
then I recommend we find a way to remove it from the head of the
repository. The feature is still available in the history and
in previous releases when it was supported.
If there is a future need for the feature and there are those that
are willing to support it, it can always be resurrected from the
history.
If it is a critical feature that will break the entire project
if it is removed, then we must find community members that are
willing to own it.
The immediate backup for this scenario is the EDK II Stewards, but
They may not have the background on the specific feature to maintain
it well. For example, I am currently helping with the NetworkPkg
because there are no maintainers and I have been recruiting without
success.
I would like the see the SignedCapulePkg removed. There are a
couple platforms in edk2-platforms that depend on it. There is
another task to review the actively supported platforms in
edk2-platforms. If those platforms are removed, then SignedCapulsePkg
could be safely removed from the head of edk2.
SourceLevelDebugPkg has a similar issues of no maintainers. The
platforms maintained in edk2 repo do not depend on it to do source
level debug. It is more of a physical platform debug capability.
Perhaps this feature should be moved to the edk2-platform. There
was a brief discuss at the UEFI Plugfest to update this debug
feature because the current one depends on very old tools.
Mike
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Monday, October 30, 2023 4:29 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; devel@edk2.groups.io; pedro.falcato@gmail.com
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
> Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray
> Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu,
> Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
>
> On 10/30/23 06:31, Kinney, Michael D wrote:
> > There is a very good discussion here on the roles and responsibility
> > and potential suggestions for changes to the Wiki page that document
> > those roles and responsibilities.
> >
> > May I suggest that someone start a new thread that discusses
> > the proposed changes to the Wiki page and leave this thread for the
> > review of the changes to Maintainers.txt?
>
> These are connected topics, but yes, back to "Maintainers.txt" -- do
> you
> feel that "S: Orphan" sections are acceptable in general? They're a
> first (AFAICT) for edk2's "Maintainers.txt"; we've always had the
> mechanism documented (since the creation of "Maintainers.txt", or so),
> but we never seem to have put it to use.
>
> Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110345): https://edk2.groups.io/g/devel/message/110345
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-30 22:18 ` Michael D Kinney
@ 2023-10-31 10:16 ` Laszlo Ersek
0 siblings, 0 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-31 10:16 UTC (permalink / raw)
To: Kinney, Michael D, Yao, Jiewen, devel@edk2.groups.io,
pedro.falcato@gmail.com
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
On 10/30/23 23:18, Kinney, Michael D wrote:
> Hi Laszlo,
>
> I do not support orphaned categories and that option should be
> removed from Maintainer.txt. One of the motivations to get
> Maintainers.txt updated is to work on the set of tasks related to
> using GitHub PRs for code review.
I see. I didn't know. So, the mailing list based review process is going
away.
> If a component is orphaned,
> then nobody would be assigned to a PR in that area and the PR
> would be stuck and would eventually be deleted for no activity.
> A terrible experience for a submitter.
I agree, although just because a PR is auto-assigned to reviewers, tehre
is no guarantee that those reviewers will provide timely feedback.
(The current, long response times on the list may have two reasons; one,
reviewers missing patches (in spite of the direct CC's); two, reviewers
not acting on the patches they are aware of. Reviewing PRs on GitHub may
help with the former, but I'm doubtful it will help with the latter.
Anyway, I'm not trying to object to the workflow change.)
> If there is a feature for which there is no longer any support,
> then I recommend we find a way to remove it from the head of the
> repository. The feature is still available in the history and
> in previous releases when it was supported.
OK!
> If there is a future need for the feature and there are those that
> are willing to support it, it can always be resurrected from the
> history.
>
> If it is a critical feature that will break the entire project
> if it is removed, then we must find community members that are
> willing to own it.
>
> The immediate backup for this scenario is the EDK II Stewards, but
> They may not have the background on the specific feature to maintain
> it well. For example, I am currently helping with the NetworkPkg
> because there are no maintainers and I have been recruiting without
> success.
It's unfortunate that NetworkPkg has no dedicated maintainer; UEFI
network boot (for example in OVMF guests) is certainly used in the industry.
I'll try to help out with patch reviews for NetworkPkg as well.
> I would like the see the SignedCapulePkg removed. There are a
> couple platforms in edk2-platforms that depend on it. There is
> another task to review the actively supported platforms in
> edk2-platforms. If those platforms are removed, then SignedCapulsePkg
> could be safely removed from the head of edk2.
... or else SignedCapulsePkg could be moved to edk2-platforms.
(While I prefer to keep everything in one big tree, I agree that moving
SignedCapulsePkg to edk2-platforms would be consistent with past
subsystem movements.)
> SourceLevelDebugPkg has a similar issues of no maintainers. The
> platforms maintained in edk2 repo do not depend on it to do source
> level debug. It is more of a physical platform debug capability.
> Perhaps this feature should be moved to the edk2-platform. There
> was a brief discuss at the UEFI Plugfest to update this debug
> feature because the current one depends on very old tools.
I'd even welcome that, as I see SOURCE_DEBUG_ENABLE an unnecessary (not
functional) complication in the OVMF DSC files.
OK, let us review the patch again from scratch, with these points in mind.
Thanks
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110394): https://edk2.groups.io/g/devel/message/110394
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-29 2:16 ` Pedro Falcato
2023-10-29 8:05 ` Yao, Jiewen
2023-10-29 13:30 ` Laszlo Ersek
@ 2023-10-30 7:38 ` Ng, Ray Han Lim
2 siblings, 0 replies; 32+ messages in thread
From: Ng, Ray Han Lim @ 2023-10-30 7:38 UTC (permalink / raw)
To: Pedro Falcato, devel@edk2.groups.io, Kinney, Michael D
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
For changes to item "> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]":
Reviewed-by: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
-----Original Message-----
From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Sunday, October 29, 2023 10:17 AM
To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Andrew Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>; Warkentin, Andrei <andrei.warkentin@intel.com>; West, Catharine <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel Schaefer <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>; Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney <michael.d.kinney@intel.com> 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 <laura.chan@intel.com>
> * 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 <sami.mujawar@arm.com> [samimujawar]
> RISCV64
> F: */RiscV64/
> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>
> LOONGARCH64
> F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> [leiflindholm]
> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [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)?
> 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 <jiewen.yao@intel.com> [jyao1]
> M: Yi Li <yi1.li@intel.com> [liyi77]
> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
>
> DynamicTablesPkg
> F: DynamicTablesPkg/
> @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Abner Chang <abner.chang@amd.com> [changab]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>
> EmulatorPkg
> F: EmulatorPkg/
> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
>
> IntelFsp2Pkg
> @@ -237,7 +224,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS] @@ -258,7
> +244,6 @@ R: Susovan Mohapatra <susovan.mohapatra@intel.com>
> [susovanmohapatra] MdeModulePkg
> F: MdeModulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
MdeModulePkg now only has a single maintainer (Liming, who also handles a myriad of other tasks and packages)
>
> MdeModulePkg: ACPI modules
> @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com>
> [LiuZhiguang001]
> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> -
> MdeModulePkg: BDS modules
> F: MdeModulePkg/*BootManager*/
> F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -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 <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
Down to one reviewer.
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
Device and bus related code is down to one reviewer.
>
> MdeModulePkg: Disk modules
> F: MdeModulePkg/Universal/Disk/
> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>
> @@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> F: MdeModulePkg/Universal/Esrt*/
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Guomin Jiang <guomin.jiang@intel.com> [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 <dandan.bi@intel.com> [dandanbi]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
One reviewer
>
> MdeModulePkg: Management Mode (MM, SMM) modules
> F: MdeModulePkg/*Smi*/
> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Pei Core
> F: MdeModulePkg/Core/Pei/
> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> -R: Catharine West <catharine.west@intel.com> [catharine-intl]
The *PEI core* is now down to one reviewer.
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
ditto
>
> MdeModulePkg: Universal Payload definitions @@ -437,7 +404,6 @@ F:
> MdeModulePkg/Library/TraceHubDebugSysTLib/
> F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> M: Prakashan Krishnadas Veliyathuparambil
> <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
>
> MdeModulePkg: USB Network modules
> @@ -497,7 +463,6 @@ F: OvmfPkg/
> W: http://www.tianocore.org/ovmf/
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> R: Corvin Köhne <corvink@freebsd.org> [corvink]
>
> OvmfPkg: cloudhv-related modules
> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>
> -OvmfPkg: CSM modules
> -F: OvmfPkg/Csm/
> -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
0 people dedicated to OVMF CSM (although relatively low maintenance overhead, from what it seems)
> -
> 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 <erdemaktas@google.com> [ruleof2]
> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> R: Min Xu <min.m.xu@intel.com> [mxu9]
> R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky] @@ -568,7
> +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> F: OvmfPkg/PlatformPei/ClearCache.c
> F: OvmfPkg/Tcg/
> R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
One reviewer
>
> 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 <anthony.perard@citrix.com> [tperard]
> -R: Julien Grall <julien@xen.org> [jgrall]
One reviewer
>
> 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 <jiewen.yao@intel.com> [jyao1]
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SecurityPkg: Secure boot related modules
> F: SecurityPkg/Library/DxeImageVerificationLib/
> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
>
> SecurityPkg: Tcg related modules
> F: SecurityPkg/Tcg/
> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
ditto
>
> ShellPkg
> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com>
> [ZhichaoGao] SignedCapsulePkg
> F: SignedCapsulePkg/
> W:
> https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
Unmaintained
>
> SourceLevelDebugPkg
> F: SourceLevelDebugPkg/
> W:
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebug
> Pkg
> -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
Unmaintained
>
> StandaloneMmPkg
> F: StandaloneMmPkg/
> @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu] UefiCpuPkg
> F: UefiCpuPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel] @@ -672,7 +624,6 @@ R:
> Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> UefiCpuPkg: Sec related modules
> F: UefiCpuPkg/SecCore/
> F: UefiCpuPkg/ResetVector/
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> R: Catharine West <catharine.west@intel.com> [catharine-intl]
One reviewer.
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 (!!!)
(HII and UI was tough to actually measure, but I'm relatively sure it's 100,000+ LoC!)
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)?
2) What's the call for action here? Should people submit themselves as new reviewers/maintainers of poorly maintained/reviewed code?
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110332): https://edk2.groups.io/g/devel/message/110332
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
2023-10-29 2:16 ` Pedro Falcato
@ 2023-10-29 21:58 ` Stefan Berger
2023-10-30 4:51 ` Peter Grehan
` (6 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Stefan Berger @ 2023-10-29 21:58 UTC (permalink / raw)
To: devel, michael.d.kinney
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, Wenxing Hou, Xiaoyu Lu
On 10/28/23 15:23, 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110278): https://edk2.groups.io/g/devel/message/110278
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
2023-10-29 2:16 ` Pedro Falcato
2023-10-29 21:58 ` Stefan Berger
@ 2023-10-30 4:51 ` Peter Grehan
2023-10-30 7:35 ` Wu, Hao A
` (5 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Peter Grehan @ 2023-10-30 4:51 UTC (permalink / raw)
To: Michael D Kinney, devel
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, Qi Zhang, Ray Han Lim Ng,
Stefan Berger, Wenxing Hou, Xiaoyu Lu
On 10/29/23 5:23 AM, 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
...
Reviewed-by: Peter Grehan <grehan@freebsd.org>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110287): https://edk2.groups.io/g/devel/message/110287
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
` (2 preceding siblings ...)
2023-10-30 4:51 ` Peter Grehan
@ 2023-10-30 7:35 ` Wu, Hao A
2023-10-30 10:51 ` Julien Grall
` (4 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Wu, Hao A @ 2023-10-30 7:35 UTC (permalink / raw)
To: Kinney, Michael D, devel@edk2.groups.io
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, James Bottomley, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1
For changes to item "Hao A Wu <hao.a.wu@intel.com> [hwu25]":
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Best Regards,
Hao Wu
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Sunday, October 29, 2023 3:24 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>; Wu,
> Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter Grehan
> <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray Han Lim
> <ray.han.lim.ng@intel.com>; Stefan Berger <stefanb@linux.ibm.com>; Hou,
> Wenxing <wenxing.hou@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: [Patch 1/1] Maintainers.txt: Update based on active community
> members
>
> 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
> ---
> Maintainers.txt | 53 ++-----------------------------------------------
> 1 file changed, 2 insertions(+), 51 deletions(-)
>
> 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 <sami.mujawar@arm.com>
> [samimujawar]
> RISCV64
> F: */RiscV64/
> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>
> LOONGARCH64
> F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> [leiflindholm]
> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [jgrall]
> -
> 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 <jiewen.yao@intel.com> [jyao1]
> M: Yi Li <yi1.li@intel.com> [liyi77]
> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
>
> DynamicTablesPkg
> F: DynamicTablesPkg/
> @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Abner Chang <abner.chang@amd.com> [changab]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>
> EmulatorPkg
> F: EmulatorPkg/
> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
>
> IntelFsp2Pkg
> @@ -237,7 +224,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS] @@ -258,7 +244,6 @@
> R: Susovan Mohapatra <susovan.mohapatra@intel.com> [susovanmohapatra]
> MdeModulePkg
> F: MdeModulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg: ACPI modules
> @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com>
> [LiuZhiguang001]
> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> -
> MdeModulePkg: BDS modules
> F: MdeModulePkg/*BootManager*/
> F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -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 <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Disk modules
> F: MdeModulePkg/Universal/Disk/
> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>
> @@ -366,7 +339,6 @@ F:
> MdeModulePkg/Library/DisplayUpdateProgressLib*/
> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> F: MdeModulePkg/Universal/Esrt*/
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
>
> 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 <dandan.bi@intel.com> [dandanbi]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
>
> MdeModulePkg: Management Mode (MM, SMM) modules
> F: MdeModulePkg/*Smi*/
> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Pei Core
> F: MdeModulePkg/Core/Pei/
> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> -R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg: Universal Payload definitions @@ -437,7 +404,6 @@ F:
> MdeModulePkg/Library/TraceHubDebugSysTLib/
> F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> M: Prakashan Krishnadas Veliyathuparambil
> <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
>
> MdeModulePkg: USB Network modules
> @@ -497,7 +463,6 @@ F: OvmfPkg/
> W: http://www.tianocore.org/ovmf/
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> R: Corvin Köhne <corvink@freebsd.org> [corvink]
>
> OvmfPkg: cloudhv-related modules
> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>
> -OvmfPkg: CSM modules
> -F: OvmfPkg/Csm/
> -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
> -
> 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 <erdemaktas@google.com> [ruleof2]
> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> R: Min Xu <min.m.xu@intel.com> [mxu9]
> R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky] @@ -568,7
> +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> F: OvmfPkg/PlatformPei/ClearCache.c
> F: OvmfPkg/Tcg/
> R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
>
> 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 <anthony.perard@citrix.com> [tperard]
> -R: Julien Grall <julien@xen.org> [jgrall]
>
> 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 <jiewen.yao@intel.com> [jyao1]
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SecurityPkg: Secure boot related modules
> F: SecurityPkg/Library/DxeImageVerificationLib/
> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
>
> SecurityPkg: Tcg related modules
> F: SecurityPkg/Tcg/
> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
>
> ShellPkg
> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com>
> [ZhichaoGao] SignedCapsulePkg
> F: SignedCapsulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SourceLevelDebugPkg
> F: SourceLevelDebugPkg/
> W:
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
> -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
>
> StandaloneMmPkg
> F: StandaloneMmPkg/
> @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu] UefiCpuPkg
> F: UefiCpuPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel] @@ -672,7 +624,6 @@ R:
> Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> UefiCpuPkg: Sec related modules
> F: UefiCpuPkg/SecCore/
> F: UefiCpuPkg/ResetVector/
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> UefiCpuPkg: AMD related files
> --
> 2.40.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110295): https://edk2.groups.io/g/devel/message/110295
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
` (3 preceding siblings ...)
2023-10-30 7:35 ` Wu, Hao A
@ 2023-10-30 10:51 ` Julien Grall
2023-10-31 4:08 ` Andrei Warkentin
` (3 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Julien Grall @ 2023-10-30 10:51 UTC (permalink / raw)
To: devel, michael.d.kinney
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, Peter Grehan, Qi Zhang, Ray Han Lim Ng,
Stefan Berger, Wenxing Hou, Xiaoyu Lu
Hi Michael,
On 28/10/2023 20:23, 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
> ---
> Maintainers.txt | 53 ++-----------------------------------------------
> 1 file changed, 2 insertions(+), 51 deletions(-)
>
> 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 <sami.mujawar@arm.com> [samimujawar]
> RISCV64
> F: */RiscV64/
> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>
> LOONGARCH64
> F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [jgrall]
> -
A few months ago, I have asked the Xen community if someone wanted to
take over the responsibility. Unfortunately, no-one step up. So this
seems to be the best approach:
Acked-by: Julien Grall <julien@xen.org>
Cheers,
--
Julien Grall
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110306): https://edk2.groups.io/g/devel/message/110306
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
` (4 preceding siblings ...)
2023-10-30 10:51 ` Julien Grall
@ 2023-10-31 4:08 ` Andrei Warkentin
2023-10-31 6:25 ` Jordan Justen
` (2 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Andrei Warkentin @ 2023-10-31 4:08 UTC (permalink / raw)
To: Kinney, Michael D, devel@edk2.groups.io
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Saturday, October 28, 2023 2:24 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine <catharine.west@intel.com>;
> Bi, Dandan <dandan.bi@intel.com>; Daniel Schaefer
> <git@danielschaefer.me>; David Woodhouse <dwmw2@infradead.org>; De,
> Debkumar <debkumar.de@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Jiang, Guomin <guomin.jiang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> James Bottomley <jejb@linux.ibm.com>; Wang, Jian J
> <jian.j.wang@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien
> Grall <julien@xen.org>; Peter Grehan <grehan@freebsd.org>; Zhang, Qi1
> <qi1.zhang@intel.com>; Ng, Ray Han Lim <ray.han.lim.ng@intel.com>; Stefan
> Berger <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>;
> Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: [Patch 1/1] Maintainers.txt: Update based on active community
> members
>
> 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
> ---
> Maintainers.txt | 53 ++-----------------------------------------------
> 1 file changed, 2 insertions(+), 51 deletions(-)
>
> 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 <sami.mujawar@arm.com>
> [samimujawar]
> RISCV64
> F: */RiscV64/
> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>
> LOONGARCH64
> F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> [leiflindholm]
> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [jgrall]
> -
> 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 <jiewen.yao@intel.com> [jyao1]
> M: Yi Li <yi1.li@intel.com> [liyi77]
> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
>
> DynamicTablesPkg
> F: DynamicTablesPkg/
> @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Abner Chang <abner.chang@amd.com> [changab]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>
> EmulatorPkg
> F: EmulatorPkg/
> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
>
> IntelFsp2Pkg
> @@ -237,7 +224,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS] @@ -258,7 +244,6 @@
> R: Susovan Mohapatra <susovan.mohapatra@intel.com> [susovanmohapatra]
> MdeModulePkg
> F: MdeModulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg: ACPI modules
> @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com>
> [LiuZhiguang001]
> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> -
> MdeModulePkg: BDS modules
> F: MdeModulePkg/*BootManager*/
> F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -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 <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Disk modules
> F: MdeModulePkg/Universal/Disk/
> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>
> @@ -366,7 +339,6 @@ F:
> MdeModulePkg/Library/DisplayUpdateProgressLib*/
> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> F: MdeModulePkg/Universal/Esrt*/
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
>
> 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 <dandan.bi@intel.com> [dandanbi]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
>
> MdeModulePkg: Management Mode (MM, SMM) modules
> F: MdeModulePkg/*Smi*/
> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Pei Core
> F: MdeModulePkg/Core/Pei/
> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> -R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg: Universal Payload definitions @@ -437,7 +404,6 @@ F:
> MdeModulePkg/Library/TraceHubDebugSysTLib/
> F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> M: Prakashan Krishnadas Veliyathuparambil
> <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
>
> MdeModulePkg: USB Network modules
> @@ -497,7 +463,6 @@ F: OvmfPkg/
> W: http://www.tianocore.org/ovmf/
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> R: Corvin Köhne <corvink@freebsd.org> [corvink]
>
> OvmfPkg: cloudhv-related modules
> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>
> -OvmfPkg: CSM modules
> -F: OvmfPkg/Csm/
> -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
> -
> 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 <erdemaktas@google.com> [ruleof2]
> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> R: Min Xu <min.m.xu@intel.com> [mxu9]
> R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky] @@ -568,7
> +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> F: OvmfPkg/PlatformPei/ClearCache.c
> F: OvmfPkg/Tcg/
> R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
>
> 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 <anthony.perard@citrix.com> [tperard]
> -R: Julien Grall <julien@xen.org> [jgrall]
>
> 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 <jiewen.yao@intel.com> [jyao1]
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SecurityPkg: Secure boot related modules
> F: SecurityPkg/Library/DxeImageVerificationLib/
> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
>
> SecurityPkg: Tcg related modules
> F: SecurityPkg/Tcg/
> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
>
> ShellPkg
> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com>
> [ZhichaoGao] SignedCapsulePkg
> F: SignedCapsulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SourceLevelDebugPkg
> F: SourceLevelDebugPkg/
> W:
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
> -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
>
> StandaloneMmPkg
> F: StandaloneMmPkg/
> @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu] UefiCpuPkg
> F: UefiCpuPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel] @@ -672,7 +624,6 @@ R:
> Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> UefiCpuPkg: Sec related modules
> F: UefiCpuPkg/SecCore/
> F: UefiCpuPkg/ResetVector/
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> UefiCpuPkg: AMD related files
> --
> 2.40.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110361): https://edk2.groups.io/g/devel/message/110361
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
` (5 preceding siblings ...)
2023-10-31 4:08 ` Andrei Warkentin
@ 2023-10-31 6:25 ` Jordan Justen
2023-10-31 10:24 ` Laszlo Ersek
2023-10-31 12:27 ` Leif Lindholm
8 siblings, 0 replies; 32+ messages in thread
From: Jordan Justen @ 2023-10-31 6:25 UTC (permalink / raw)
To: Michael D Kinney, devel; +Cc: Andrew Fish, Leif Lindholm
On 2023-10-28 12:23:30, Michael D Kinney wrote:
> @@ -497,7 +463,6 @@ F: OvmfPkg/
> W: http://www.tianocore.org/ovmf/
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> S: Maintained
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110373): https://edk2.groups.io/g/devel/message/110373
Mute This Topic: https://groups.io/mt/102245264/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
` (6 preceding siblings ...)
2023-10-31 6:25 ` Jordan Justen
@ 2023-10-31 10:24 ` Laszlo Ersek
2023-11-05 1:22 ` Michael D Kinney
2023-10-31 12:27 ` Leif Lindholm
8 siblings, 1 reply; 32+ messages in thread
From: Laszlo Ersek @ 2023-10-31 10:24 UTC (permalink / raw)
To: devel, michael.d.kinney
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
On 10/28/23 21:23, 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
> ---
> Maintainers.txt | 53 ++-----------------------------------------------
> 1 file changed, 2 insertions(+), 51 deletions(-)
FWIW:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Additionally, based on Mike's explanation down-thread, I'm proposing:
- a follow-up patch to Maintainers.txt where we remove the "Orphan"
status from the generic description,
- filing three separate BZs, for the removal of OvmfPkg/Csm/,
SignedCapsulePkg, and SourceLevelDebugPkg, respectively (where the
latter two could be moved to edk2-platforms),
- I'm happy to take on the OvmfPkg/Csm/ removal BZ.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110395): https://edk2.groups.io/g/devel/message/110395
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-31 10:24 ` Laszlo Ersek
@ 2023-11-05 1:22 ` Michael D Kinney
2023-11-05 10:28 ` Laszlo Ersek
0 siblings, 1 reply; 32+ messages in thread
From: Michael D Kinney @ 2023-11-05 1:22 UTC (permalink / raw)
To: Laszlo Ersek, devel@edk2.groups.io
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1, Kinney, Michael D
Hi Laszlo,
I have sent patch review to remove Orphan status option from Maintainers.txt.
I have also opened the following 3 BZs
OvmfPkg/CSM: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
SignedCapsulePkg: https://bugzilla.tianocore.org/show_bug.cgi?id=4589
SourceLevelDebugPkg: https://bugzilla.tianocore.org/show_bug.cgi?id=4590
Best regards,
Mike
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, October 31, 2023 3:25 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
> Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray
> Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu,
> Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
>
> On 10/28/23 21:23, 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 <laura.chan@intel.com>
> > * Many smaller updates removing individuals that are no
> > longer involved or have replacement coverage.
> >
> > Cc: Andrew Fish <afish@apple.com>
> > Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> > Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> > Cc: Catharine West <catharine.west@intel.com>
> > Cc: Dandan Bi <dandan.bi@intel.com>
> > Cc: Daniel Schaefer <git@danielschaefer.me>
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Cc: Debkumar De <debkumar.de@intel.com>
> > Cc: Eric Dong <eric.dong@intel.com>
> > Cc: Guomin Jiang <guomin.jiang@intel.com>
> > Cc: Hao A Wu <hao.a.wu@intel.com>
> > Cc: James Bottomley <jejb@linux.ibm.com>
> > Cc: Jian J Wang <jian.j.wang@intel.com>
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Cc: Julien Grall <julien@xen.org>
> > Cc: Peter Grehan <grehan@freebsd.org>
> > Cc: Qi Zhang <qi1.zhang@intel.com>
> > Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> > Cc: Stefan Berger <stefanb@linux.ibm.com>
> > Cc: Wenxing Hou <wenxing.hou@intel.com>
> > Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> > Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
> > ---
> > Maintainers.txt | 53 ++--------------------------------------------
> ---
> > 1 file changed, 2 insertions(+), 51 deletions(-)
>
> FWIW:
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>
> Additionally, based on Mike's explanation down-thread, I'm proposing:
>
> - a follow-up patch to Maintainers.txt where we remove the "Orphan"
> status from the generic description,
>
> - filing three separate BZs, for the removal of OvmfPkg/Csm/,
> SignedCapsulePkg, and SourceLevelDebugPkg, respectively (where the
> latter two could be moved to edk2-platforms),
>
> - I'm happy to take on the OvmfPkg/Csm/ removal BZ.
>
> Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110676): https://edk2.groups.io/g/devel/message/110676
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-11-05 1:22 ` Michael D Kinney
@ 2023-11-05 10:28 ` Laszlo Ersek
0 siblings, 0 replies; 32+ messages in thread
From: Laszlo Ersek @ 2023-11-05 10:28 UTC (permalink / raw)
To: Kinney, Michael D, devel@edk2.groups.io
Cc: Andrew Fish, Leif Lindholm, Warkentin, Andrei, West, Catharine,
Bi, Dandan, Daniel Schaefer, David Woodhouse, De, Debkumar,
Dong, Eric, Jiang, Guomin, Wu, Hao A, James Bottomley,
Wang, Jian J, Justen, Jordan L, Julien Grall, Peter Grehan,
Zhang, Qi1, Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing,
Lu, Xiaoyu1
On 11/5/23 02:22, Kinney, Michael D wrote:
> Hi Laszlo,
>
> I have sent patch review to remove Orphan status option from Maintainers.txt.
>
> I have also opened the following 3 BZs
>
> OvmfPkg/CSM: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
> SignedCapsulePkg: https://bugzilla.tianocore.org/show_bug.cgi?id=4589
> SourceLevelDebugPkg: https://bugzilla.tianocore.org/show_bug.cgi?id=4590
Thanks, I've taken <https://bugzilla.tianocore.org/show_bug.cgi?id=4588>.
Laszlo
>
> Best regards,
>
> Mike
>
>> -----Original Message-----
>> From: Laszlo Ersek <lersek@redhat.com>
>> Sent: Tuesday, October 31, 2023 3:25 AM
>> To: devel@edk2.groups.io; Kinney, Michael D
>> <michael.d.kinney@intel.com>
>> Cc: Andrew Fish <afish@apple.com>; Leif Lindholm
>> <quic_llindhol@quicinc.com>; Warkentin, Andrei
>> <andrei.warkentin@intel.com>; West, Catharine
>> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
>> Schaefer <git@danielschaefer.me>; David Woodhouse
>> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
>> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
>> Wu, Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>;
>> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
>> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
>> Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray
>> Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
>> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu,
>> Xiaoyu1 <xiaoyu1.lu@intel.com>
>> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
>> active community members
>>
>> On 10/28/23 21:23, 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 <laura.chan@intel.com>
>>> * Many smaller updates removing individuals that are no
>>> longer involved or have replacement coverage.
>>>
>>> Cc: Andrew Fish <afish@apple.com>
>>> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
>>> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
>>> Cc: Catharine West <catharine.west@intel.com>
>>> Cc: Dandan Bi <dandan.bi@intel.com>
>>> Cc: Daniel Schaefer <git@danielschaefer.me>
>>> Cc: David Woodhouse <dwmw2@infradead.org>
>>> Cc: Debkumar De <debkumar.de@intel.com>
>>> Cc: Eric Dong <eric.dong@intel.com>
>>> Cc: Guomin Jiang <guomin.jiang@intel.com>
>>> Cc: Hao A Wu <hao.a.wu@intel.com>
>>> Cc: James Bottomley <jejb@linux.ibm.com>
>>> Cc: Jian J Wang <jian.j.wang@intel.com>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Cc: Julien Grall <julien@xen.org>
>>> Cc: Peter Grehan <grehan@freebsd.org>
>>> Cc: Qi Zhang <qi1.zhang@intel.com>
>>> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
>>> Cc: Stefan Berger <stefanb@linux.ibm.com>
>>> Cc: Wenxing Hou <wenxing.hou@intel.com>
>>> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
>>> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
>>> ---
>>> Maintainers.txt | 53 ++--------------------------------------------
>> ---
>>> 1 file changed, 2 insertions(+), 51 deletions(-)
>>
>> FWIW:
>>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>>
>> Additionally, based on Mike's explanation down-thread, I'm proposing:
>>
>> - a follow-up patch to Maintainers.txt where we remove the "Orphan"
>> status from the generic description,
>>
>> - filing three separate BZs, for the removal of OvmfPkg/Csm/,
>> SignedCapsulePkg, and SourceLevelDebugPkg, respectively (where the
>> latter two could be moved to edk2-platforms),
>>
>> - I'm happy to take on the OvmfPkg/Csm/ removal BZ.
>>
>> Laszlo
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110679): https://edk2.groups.io/g/devel/message/110679
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-28 19:23 [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members Michael D Kinney
` (7 preceding siblings ...)
2023-10-31 10:24 ` Laszlo Ersek
@ 2023-10-31 12:27 ` Leif Lindholm
2023-11-04 23:25 ` Michael D Kinney
8 siblings, 1 reply; 32+ messages in thread
From: Leif Lindholm @ 2023-10-31 12:27 UTC (permalink / raw)
To: devel, michael.d.kinney
Cc: Andrew Fish, 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
On Sat, Oct 28, 2023 at 12:23:30 -0700, 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 <laura.chan@intel.com>
> * Many smaller updates removing individuals that are no
> longer involved or have replacement coverage.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Catharine West <catharine.west@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Daniel Schaefer <git@danielschaefer.me>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Debkumar De <debkumar.de@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guomin Jiang <guomin.jiang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Peter Grehan <grehan@freebsd.org>
> Cc: Qi Zhang <qi1.zhang@intel.com>
> Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
> Cc: Wenxing Hou <wenxing.hou@intel.com>
> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
(I have some comments for later in the thread, but they do not affect
this patch.)
/
Leif
> ---
> Maintainers.txt | 53 ++-----------------------------------------------
> 1 file changed, 2 insertions(+), 51 deletions(-)
>
> 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 <sami.mujawar@arm.com> [samimujawar]
> RISCV64
> F: */RiscV64/
> M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
>
> LOONGARCH64
> F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [jgrall]
> -
> 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 <jiewen.yao@intel.com> [jyao1]
> M: Yi Li <yi1.li@intel.com> [liyi77]
> -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
>
> DynamicTablesPkg
> F: DynamicTablesPkg/
> @@ -202,7 +191,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Abner Chang <abner.chang@amd.com> [changab]
> -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
>
> EmulatorPkg
> F: EmulatorPkg/
> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
>
> IntelFsp2Pkg
> @@ -237,7 +224,6 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> R: Star Zeng <star.zeng@intel.com> [lzeng14]
> R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> @@ -258,7 +244,6 @@ R: Susovan Mohapatra <susovan.mohapatra@intel.com> [susovanmohapatra]
> MdeModulePkg
> F: MdeModulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg: ACPI modules
> @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]
> R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
> -
> MdeModulePkg: BDS modules
> F: MdeModulePkg/*BootManager*/
> F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -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 <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Disk modules
> F: MdeModulePkg/Universal/Disk/
> -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> R: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
>
> @@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
> F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> F: MdeModulePkg/Universal/Esrt*/
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
>
> 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 <dandan.bi@intel.com> [dandanbi]
> -R: Eric Dong <eric.dong@intel.com> [ydong10]
>
> MdeModulePkg: Management Mode (MM, SMM) modules
> F: MdeModulePkg/*Smi*/
> @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
>
> MdeModulePkg: Pei Core
> F: MdeModulePkg/Core/Pei/
> -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> -R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> 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 <hao.a.wu@intel.com> [hwu25]
> R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
>
> MdeModulePkg: Universal Payload definitions
> @@ -437,7 +404,6 @@ F: MdeModulePkg/Library/TraceHubDebugSysTLib/
> F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> M: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> -R: Chan Laura <laura.chan@intel.com> [lauracha]
> R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
>
> MdeModulePkg: USB Network modules
> @@ -497,7 +463,6 @@ F: OvmfPkg/
> W: http://www.tianocore.org/ovmf/
> M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> R: Corvin Köhne <corvink@freebsd.org> [corvink]
>
> OvmfPkg: cloudhv-related modules
> @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
>
> -OvmfPkg: CSM modules
> -F: OvmfPkg/Csm/
> -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
> -
> 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 <erdemaktas@google.com> [ruleof2]
> -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> R: Min Xu <min.m.xu@intel.com> [mxu9]
> R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
> @@ -568,7 +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> F: OvmfPkg/PlatformPei/ClearCache.c
> F: OvmfPkg/Tcg/
> R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
>
> 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 <anthony.perard@citrix.com> [tperard]
> -R: Julien Grall <julien@xen.org> [jgrall]
>
> 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 <jiewen.yao@intel.com> [jyao1]
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SecurityPkg: Secure boot related modules
> F: SecurityPkg/Library/DxeImageVerificationLib/
> @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
>
> SecurityPkg: Tcg related modules
> F: SecurityPkg/Tcg/
> -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
>
> ShellPkg
> @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> SignedCapsulePkg
> F: SignedCapsulePkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
>
> SourceLevelDebugPkg
> F: SourceLevelDebugPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
> -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
>
> StandaloneMmPkg
> F: StandaloneMmPkg/
> @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu]
> UefiCpuPkg
> F: UefiCpuPkg/
> W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> -M: Eric Dong <eric.dong@intel.com> [ydong10]
> M: Ray Ni <ray.ni@intel.com> [niruiyu]
> R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> UefiCpuPkg: Sec related modules
> F: UefiCpuPkg/SecCore/
> F: UefiCpuPkg/ResetVector/
> -R: Debkumar De <debkumar.de@intel.com> [dde01]
> R: Catharine West <catharine.west@intel.com> [catharine-intl]
>
> UefiCpuPkg: AMD related files
> --
> 2.40.1.windows.1
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110406): https://edk2.groups.io/g/devel/message/110406
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members
2023-10-31 12:27 ` Leif Lindholm
@ 2023-11-04 23:25 ` Michael D Kinney
0 siblings, 0 replies; 32+ messages in thread
From: Michael D Kinney @ 2023-11-04 23:25 UTC (permalink / raw)
To: devel@edk2.groups.io, quic_llindhol@quicinc.com
Cc: Andrew Fish, Warkentin, Andrei, West, Catharine, Bi, Dandan,
Daniel Schaefer, David Woodhouse, De, Debkumar, Dong, Eric,
Jiang, Guomin, Wu, Hao A, James Bottomley, Wang, Jian J,
Justen, Jordan L, Julien Grall, Peter Grehan, Zhang, Qi1,
Ng, Ray Han Lim, Stefan Berger, Hou, Wenxing, Lu, Xiaoyu1,
Kinney, Michael D
Merged: https://github.com/tianocore/edk2/pull/5001
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Leif
> Lindholm
> Sent: Tuesday, October 31, 2023 5:27 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Warkentin, Andrei
> <andrei.warkentin@intel.com>; West, Catharine
> <catharine.west@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Daniel
> Schaefer <git@danielschaefer.me>; David Woodhouse
> <dwmw2@infradead.org>; De, Debkumar <debkumar.de@intel.com>; Dong,
> Eric <eric.dong@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; James Bottomley <jejb@linux.ibm.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall <julien@xen.org>; Peter
> Grehan <grehan@freebsd.org>; Zhang, Qi1 <qi1.zhang@intel.com>; Ng, Ray
> Han Lim <ray.han.lim.ng@intel.com>; Stefan Berger
> <stefanb@linux.ibm.com>; Hou, Wenxing <wenxing.hou@intel.com>; Lu,
> Xiaoyu1 <xiaoyu1.lu@intel.com>
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
>
> On Sat, Oct 28, 2023 at 12:23:30 -0700, 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 <laura.chan@intel.com>
> > * Many smaller updates removing individuals that are no
> > longer involved or have replacement coverage.
> >
> > Cc: Andrew Fish <afish@apple.com>
> > Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> > Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> > Cc: Catharine West <catharine.west@intel.com>
> > Cc: Dandan Bi <dandan.bi@intel.com>
> > Cc: Daniel Schaefer <git@danielschaefer.me>
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Cc: Debkumar De <debkumar.de@intel.com>
> > Cc: Eric Dong <eric.dong@intel.com>
> > Cc: Guomin Jiang <guomin.jiang@intel.com>
> > Cc: Hao A Wu <hao.a.wu@intel.com>
> > Cc: James Bottomley <jejb@linux.ibm.com>
> > Cc: Jian J Wang <jian.j.wang@intel.com>
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Cc: Julien Grall <julien@xen.org>
> > Cc: Peter Grehan <grehan@freebsd.org>
> > Cc: Qi Zhang <qi1.zhang@intel.com>
> > Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
> > Cc: Stefan Berger <stefanb@linux.ibm.com>
> > Cc: Wenxing Hou <wenxing.hou@intel.com>
> > Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
> > Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
>
> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
>
> (I have some comments for later in the thread, but they do not affect
> this patch.)
>
> /
> Leif
>
> > ---
> > Maintainers.txt | 53 ++--------------------------------------------
> ---
> > 1 file changed, 2 insertions(+), 51 deletions(-)
> >
> > 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 <sami.mujawar@arm.com>
> [samimujawar]
> > RISCV64
> > F: */RiscV64/
> > M: Sunil V L <sunilvl@ventanamicro.com> [vlsunil]
> > -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> > +R: Andrei Warkentin <andrei.warkentin@intel.com> [andreiw]
> >
> > LOONGARCH64
> > F: */LoongArch64/
> > @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llindhol@quicinc.com>
> [leiflindholm]
> > R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
> > R: Gerd Hoffmann <kraxel@redhat.com> [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 <julien@xen.org> [jgrall]
> > -
> > 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 <jiewen.yao@intel.com> [jyao1]
> > M: Yi Li <yi1.li@intel.com> [liyi77]
> > -R: Xiaoyu Lu <xiaoyu1.lu@intel.com> [xiaoyuxlu]
> > -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> > +R: Wenxing Hou <wenxing.hou@intel.com> [Wenxing-hou]
> >
> > DynamicTablesPkg
> > F: DynamicTablesPkg/
> > @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> > M: Leif Lindholm <quic_llindhol@quicinc.com> [leiflindholm]
> > M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> > M: Abner Chang <abner.chang@amd.com> [changab]
> > -R: Daniel Schaefer <git@danielschaefer.me> [JohnAZoidberg]
> >
> > EmulatorPkg
> > F: EmulatorPkg/
> > @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> > W:
> https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> > M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
> > -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> > R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]
> >
> > IntelFsp2Pkg
> > @@ -237,7 +224,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
> > M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
> > M: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
> > M: Duggapu Chinni B <chinni.b.duggapu@intel.com> [cbduggap]
> > -M: Ray Han Lim Ng <ray.han.lim.ng@intel.com> [rayhanlimng]
> > R: Star Zeng <star.zeng@intel.com> [lzeng14]
> > R: Ted Kuo <ted.kuo@intel.com> [tedkuo1]
> > R: Ashraf Ali S <ashraf.ali.s@intel.com> [AshrafAliS]
> > @@ -258,7 +244,6 @@ R: Susovan Mohapatra
> <susovan.mohapatra@intel.com> [susovanmohapatra]
> > MdeModulePkg
> > F: MdeModulePkg/
> > W:
> https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> > -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> > M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >
> > MdeModulePkg: ACPI modules
> > @@ -268,15 +253,6 @@ R: Zhiguang Liu <zhiguang.liu@intel.com>
> [LiuZhiguang001]
> > R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [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 <hao.a.wu@intel.com> [hwu25]
> > -R: Eric Dong <eric.dong@intel.com> [ydong10]
> > -
> > MdeModulePkg: BDS modules
> > F: MdeModulePkg/*BootManager*/
> > F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> > @@ -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 <dandan.bi@intel.com> [dandanbi]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >
> > 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 <hao.a.wu@intel.com> [hwu25]
> > R: Ray Ni <ray.ni@intel.com> [niruiyu]
> >
> > MdeModulePkg: Disk modules
> > F: MdeModulePkg/Universal/Disk/
> > -R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> > R: Ray Ni <ray.ni@intel.com> [niruiyu]
> > R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
> >
> > @@ -366,7 +339,6 @@ F:
> MdeModulePkg/Library/DisplayUpdateProgressLib*/
> > F: MdeModulePkg/Library/FmpAuthenticationLibNull/
> > F: MdeModulePkg/Universal/Esrt*/
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > -R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
> >
> > 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 <dandan.bi@intel.com> [dandanbi]
> > -R: Eric Dong <eric.dong@intel.com> [ydong10]
> >
> > MdeModulePkg: Management Mode (MM, SMM) modules
> > F: MdeModulePkg/*Smi*/
> > @@ -395,10 +366,7 @@ R: Ray Ni <ray.ni@intel.com> [niruiyu]
> >
> > MdeModulePkg: Pei Core
> > F: MdeModulePkg/Core/Pei/
> > -R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> > -R: Debkumar De <debkumar.de@intel.com> [dde01]
> > -R: Catharine West <catharine.west@intel.com> [catharine-intl]
> >
> > 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 <hao.a.wu@intel.com> [hwu25]
> > R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
> >
> > MdeModulePkg: Universal Payload definitions
> > @@ -437,7 +404,6 @@ F: MdeModulePkg/Library/TraceHubDebugSysTLib/
> > F: MdeModulePkg/Include/Guid/TraceHubDebugInfoHob.h
> > M: Gua Guo <gua.guo@intel.com> [gguo11837463]
> > M: Prakashan Krishnadas Veliyathuparambil
> <krishnadas.veliyathuparambil.prakashan@intel.com> [kprakas2]
> > -R: Chan Laura <laura.chan@intel.com> [lauracha]
> > R: K N Karthik <karthik.k.n@intel.com> [karthikkabbigere1]
> >
> > MdeModulePkg: USB Network modules
> > @@ -497,7 +463,6 @@ F: OvmfPkg/
> > W: http://www.tianocore.org/ovmf/
> > M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
> > M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> > -R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
> > R: Gerd Hoffmann <kraxel@redhat.com> [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 <rebecca@bsdio.com> [bcran]
> > -R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]
> > R: Corvin Köhne <corvink@freebsd.org> [corvink]
> >
> > OvmfPkg: cloudhv-related modules
> > @@ -528,10 +492,6 @@ F: OvmfPkg/Include/IndustryStandard/Microvm.h
> > F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> > R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> >
> > -OvmfPkg: CSM modules
> > -F: OvmfPkg/Csm/
> > -R: David Woodhouse <dwmw2@infradead.org> [dwmw2]
> > -
> > 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 <erdemaktas@google.com> [ruleof2]
> > -R: James Bottomley <jejb@linux.ibm.com> [jejb]
> > R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
> > R: Min Xu <min.m.xu@intel.com> [mxu9]
> > R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
> > @@ -568,7 +527,6 @@ F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
> > F: OvmfPkg/PlatformPei/ClearCache.c
> > F: OvmfPkg/Tcg/
> > R: Marc-André Lureau <marcandre.lureau@redhat.com> [elmarco]
> > -R: Stefan Berger <stefanb@linux.ibm.com> [stefanberger]
> >
> > 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 <anthony.perard@citrix.com> [tperard]
> > -R: Julien Grall <julien@xen.org> [jgrall]
> >
> > 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 <jiewen.yao@intel.com> [jyao1]
> > -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >
> > SecurityPkg: Secure boot related modules
> > F: SecurityPkg/Library/DxeImageVerificationLib/
> > @@ -637,7 +593,6 @@ R: Min Xu <min.m.xu@intel.com> [mxu9]
> >
> > SecurityPkg: Tcg related modules
> > F: SecurityPkg/Tcg/
> > -R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
> > R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> >
> > ShellPkg
> > @@ -648,12 +603,10 @@ M: Zhichao Gao <zhichao.gao@intel.com>
> [ZhichaoGao]
> > SignedCapsulePkg
> > F: SignedCapsulePkg/
> > W:
> https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> > -M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
> >
> > SourceLevelDebugPkg
> > F: SourceLevelDebugPkg/
> > W:
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebug
> Pkg
> > -M: Hao A Wu <hao.a.wu@intel.com> [hwu25]
> >
> > StandaloneMmPkg
> > F: StandaloneMmPkg/
> > @@ -664,7 +617,6 @@ M: Ray Ni <ray.ni@intel.com> [niruiyu]
> > UefiCpuPkg
> > F: UefiCpuPkg/
> > W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> > -M: Eric Dong <eric.dong@intel.com> [ydong10]
> > M: Ray Ni <ray.ni@intel.com> [niruiyu]
> > R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]
> > R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kraxel@redhat.com> [kraxel]
> > UefiCpuPkg: Sec related modules
> > F: UefiCpuPkg/SecCore/
> > F: UefiCpuPkg/ResetVector/
> > -R: Debkumar De <debkumar.de@intel.com> [dde01]
> > R: Catharine West <catharine.west@intel.com> [catharine-intl]
> >
> > UefiCpuPkg: AMD related files
> > --
> > 2.40.1.windows.1
> >
> >
> >
> >
> >
> >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110673): https://edk2.groups.io/g/devel/message/110673
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 32+ messages in thread