> 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/SourceLevelDebugPkg > >> -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 (#110285): https://edk2.groups.io/g/devel/message/110285 Mute This Topic: https://groups.io/mt/102245264/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
