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....@intel.com> > Sent: Sunday, October 29, 2023 7:54 PM > To: devel@edk2.groups.io; ler...@redhat.com; pedro.falc...@gmail.com; > Kinney, Michael D <michael.d.kin...@intel.com> > Cc: Andrew Fish <af...@apple.com>; Leif Lindholm > <quic_llind...@quicinc.com>; Warkentin, Andrei > <andrei.warken...@intel.com>; West, Catharine > <catharine.w...@intel.com>; Bi, Dandan <dandan...@intel.com>; Daniel > Schaefer <g...@danielschaefer.me>; David Woodhouse > <dw...@infradead.org>; De, Debkumar <debkumar...@intel.com>; Dong, > Eric <eric.d...@intel.com>; Jiang, Guomin <guomin.ji...@intel.com>; > Wu, Hao A <hao.a...@intel.com>; James Bottomley <j...@linux.ibm.com>; > Wang, Jian J <jian.j.w...@intel.com>; Justen, Jordan L > <jordan.l.jus...@intel.com>; Julien Grall <jul...@xen.org>; Peter > Grehan <gre...@freebsd.org>; Zhang, Qi1 <qi1.zh...@intel.com>; Ng, Ray > Han Lim <ray.han.lim...@intel.com>; Stefan Berger > <stef...@linux.ibm.com>; Hou, Wenxing <wenxing....@intel.com>; Lu, > Xiaoyu1 <xiaoyu1...@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.falc...@gmail.com; Kinney, Michael D > > <michael.d.kin...@intel.com> > > Cc: Andrew Fish <af...@apple.com>; Leif Lindholm > <quic_llind...@quicinc.com>; > > Warkentin, Andrei <andrei.warken...@intel.com>; West, Catharine > > <catharine.w...@intel.com>; Bi, Dandan <dandan...@intel.com>; Daniel > > Schaefer <g...@danielschaefer.me>; David Woodhouse > <dw...@infradead.org>; > > De, Debkumar <debkumar...@intel.com>; Dong, Eric > <eric.d...@intel.com>; > > Jiang, Guomin <guomin.ji...@intel.com>; Wu, Hao A > <hao.a...@intel.com>; > > James Bottomley <j...@linux.ibm.com>; Wang, Jian J > <jian.j.w...@intel.com>; > > Justen, Jordan L <jordan.l.jus...@intel.com>; Julien Grall > <jul...@xen.org>; > > Peter Grehan <gre...@freebsd.org>; Zhang, Qi1 <qi1.zh...@intel.com>; > Ng, > > Ray Han Lim <ray.han.lim...@intel.com>; Stefan Berger > > <stef...@linux.ibm.com>; Hou, Wenxing <wenxing....@intel.com>; Lu, > Xiaoyu1 > > <xiaoyu1...@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.kin...@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.c...@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.muja...@arm.com> > > [samimujawar] > > >> RISCV64 > > >> F: */RiscV64/ > > >> M: Sunil V L <suni...@ventanamicro.com> [vlsunil] > > >> -R: Daniel Schaefer <g...@danielschaefer.me> [JohnAZoidberg] > > >> +R: Andrei Warkentin <andrei.warken...@intel.com> [andreiw] > > >> > > >> LOONGARCH64 > > >> F: */LoongArch64/ > > >> @@ -157,16 +157,6 @@ R: Leif Lindholm <quic_llind...@quicinc.com> > > [leiflindholm] > > >> R: Sami Mujawar <sami.muja...@arm.com> [samimujawar] > > >> R: Gerd Hoffmann <kra...@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 <jul...@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....@intel.com> [jyao1] > > >> M: Yi Li <yi1...@intel.com> [liyi77] > > >> -R: Xiaoyu Lu <xiaoyu1...@intel.com> [xiaoyuxlu] > > >> -R: Guomin Jiang <guomin.ji...@intel.com> [guominjia] > > >> +R: Wenxing Hou <wenxing....@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_llind...@quicinc.com> [leiflindholm] > > >> M: Ard Biesheuvel <ardb+tianoc...@kernel.org> [ardbiesheuvel] > > >> M: Abner Chang <abner.ch...@amd.com> [changab] > > >> -R: Daniel Schaefer <g...@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 <gaolim...@byosoft.com.cn> [lgao4] > > >> M: Michael D Kinney <michael.d.kin...@intel.com> [mdkinney] > > >> -R: Guomin Jiang <guomin.ji...@intel.com> [guominjia] > > >> R: Wei6 Xu <wei6...@intel.com> [xuweiintel] > > >> > > >> IntelFsp2Pkg > > >> @@ -237,7 +224,6 @@ W: > > https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg > > >> M: Chasel Chiu <chasel.c...@intel.com> [ChaselChiu] > > >> M: Nate DeSimone <nathaniel.l.desim...@intel.com> [nate- > desimone] > > >> M: Duggapu Chinni B <chinni.b.dugg...@intel.com> [cbduggap] > > >> -M: Ray Han Lim Ng <ray.han.lim...@intel.com> [rayhanlimng] > > >> R: Star Zeng <star.z...@intel.com> [lzeng14] > > >> R: Ted Kuo <ted....@intel.com> [tedkuo1] > > >> R: Ashraf Ali S <ashraf.al...@intel.com> [AshrafAliS] > > >> @@ -258,7 +244,6 @@ R: Susovan Mohapatra > > <susovan.mohapa...@intel.com> [susovanmohapatra] > > >> MdeModulePkg > > >> F: MdeModulePkg/ > > >> W: > https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg > > >> -M: Jian J Wang <jian.j.w...@intel.com> [jwang36] > > >> M: Liming Gao <gaolim...@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....@intel.com> > > [LiuZhiguang001] > > >> R: Dandan Bi <dandan...@intel.com> [dandanbi] > > >> R: Liming Gao <gaolim...@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...@intel.com> [hwu25] > > >> -R: Eric Dong <eric.d...@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...@intel.com> [dandanbi] > > >> R: Liming Gao <gaolim...@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...@intel.com> [hwu25] > > >> R: Ray Ni <ray...@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...@intel.com> [hwu25] > > >> R: Ray Ni <ray...@intel.com> [niruiyu] > > >> R: Zhichao Gao <zhichao....@intel.com> [ZhichaoGao] > > >> > > >> @@ -366,7 +339,6 @@ F: > > MdeModulePkg/Library/DisplayUpdateProgressLib*/ > > >> F: MdeModulePkg/Library/FmpAuthenticationLibNull/ > > >> F: MdeModulePkg/Universal/Esrt*/ > > >> R: Liming Gao <gaolim...@byosoft.com.cn> [lgao4] > > >> -R: Guomin Jiang <guomin.ji...@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...@intel.com> [dandanbi] > > >> -R: Eric Dong <eric.d...@intel.com> [ydong10] > > > > > > One reviewer > > >> > > >> MdeModulePkg: Management Mode (MM, SMM) modules > > >> F: MdeModulePkg/*Smi*/ > > >> @@ -395,10 +366,7 @@ R: Ray Ni <ray...@intel.com> [niruiyu] > > >> > > >> MdeModulePkg: Pei Core > > >> F: MdeModulePkg/Core/Pei/ > > >> -R: Dandan Bi <dandan...@intel.com> [dandanbi] > > >> R: Liming Gao <gaolim...@byosoft.com.cn> [lgao4] > > >> -R: Debkumar De <debkumar...@intel.com> [dde01] > > >> -R: Catharine West <catharine.w...@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...@intel.com> [hwu25] > > >> R: Liming Gao <gaolim...@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....@intel.com> [gguo11837463] > > >> M: Prakashan Krishnadas Veliyathuparambil > > <krishnadas.veliyathuparambil.prakas...@intel.com> [kprakas2] > > >> -R: Chan Laura <laura.c...@intel.com> [lauracha] > > >> R: K N Karthik <karthik....@intel.com> [karthikkabbigere1] > > >> > > >> MdeModulePkg: USB Network modules > > >> @@ -497,7 +463,6 @@ F: OvmfPkg/ > > >> W: http://www.tianocore.org/ovmf/ > > >> M: Ard Biesheuvel <ardb+tianoc...@kernel.org> [ardbiesheuvel] > > >> M: Jiewen Yao <jiewen....@intel.com> [jyao1] > > >> -R: Jordan Justen <jordan.l.jus...@intel.com> [jljusten] > > >> R: Gerd Hoffmann <kra...@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 <rebe...@bsdio.com> [bcran] > > >> -R: Peter Grehan <gre...@freebsd.org> [grehan-freebsd] > > >> R: Corvin Köhne <corv...@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 <kra...@redhat.com> [kraxel] > > >> > > >> -OvmfPkg: CSM modules > > >> -F: OvmfPkg/Csm/ > > >> -R: David Woodhouse <dw...@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 <erdemak...@google.com> [ruleof2] > > >> -R: James Bottomley <j...@linux.ibm.com> [jejb] > > >> R: Jiewen Yao <jiewen....@intel.com> [jyao1] > > >> R: Min Xu <min.m...@intel.com> [mxu9] > > >> R: Tom Lendacky <thomas.lenda...@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.lur...@redhat.com> [elmarco] > > >> -R: Stefan Berger <stef...@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.per...@citrix.com> [tperard] > > >> -R: Julien Grall <jul...@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....@intel.com> [jyao1] > > >> -M: Jian J Wang <jian.j.w...@intel.com> [jwang36] > > >> > > >> SecurityPkg: Secure boot related modules > > >> F: SecurityPkg/Library/DxeImageVerificationLib/ > > >> @@ -637,7 +593,6 @@ R: Min Xu <min.m...@intel.com> [mxu9] > > >> > > >> SecurityPkg: Tcg related modules > > >> F: SecurityPkg/Tcg/ > > >> -R: Qi Zhang <qi1.zh...@intel.com> [qizhangz] > > >> R: Rahul Kumar <rahul1.ku...@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....@intel.com> > > [ZhichaoGao] > > >> SignedCapsulePkg > > >> F: SignedCapsulePkg/ > > >> W: > https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg > > >> -M: Jian J Wang <jian.j.w...@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...@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...@intel.com> [niruiyu] > > >> UefiCpuPkg > > >> F: UefiCpuPkg/ > > >> W: > https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg > > >> -M: Eric Dong <eric.d...@intel.com> [ydong10] > > >> M: Ray Ni <ray...@intel.com> [niruiyu] > > >> R: Rahul Kumar <rahul1.ku...@intel.com> [rahul1-kumar] > > >> R: Gerd Hoffmann <kra...@redhat.com> [kraxel] > > >> @@ -672,7 +624,6 @@ R: Gerd Hoffmann <kra...@redhat.com> [kraxel] > > >> UefiCpuPkg: Sec related modules > > >> F: UefiCpuPkg/SecCore/ > > >> F: UefiCpuPkg/ResetVector/ > > >> -R: Debkumar De <debkumar...@intel.com> [dde01] > > >> R: Catharine West <catharine.w...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
