On 03/09/20 07:08, Sean via Groups.Io wrote: > Ard/Lazlo, > > I find your position on OvmfPkg, ArmVirtPkg,and edk2-platforms in edk2 > to be detrimental to the overall success of the edk2 project. The > majority of edk2 consumers already have to deal with their platform > not being part of the edk2 git repo and the fact that changes to edk2 > may not work or cause conflict on their platforms. This is the > reality of working with edk2
This may be the reality for proprietary downstreams that don't, or hardly, upstream their changes, The reality that I have known, since joining the project in 2011, is that OVMF had been in the tree before I joined. And we added ArmVirtPkg in 2014 (or so) similarly. (It bore a different name back then.) > and building a large diverse set of products. In fact, because OVMF's > preferential treatment You are making it appear as if I wanted to keep OVMF in the tree and at the same time kick other platforms out of the tree, or otherwise stymie core contributions motivated by other platforms' needs. That couldn't be farther from the truth. I have stated on multiple occasions that I wish all edk2 consuming platforms to be in-tree. > and presence in the edk2 tree, others in the community are burdened by > those changes (mailing list noise, git history/commits, git repo size, > etc). Please run git log and check my contributions in the edk2 history that fall outside of OvmfPkg and ArmVirtPkg. $ git log --oneline --reverse \ --author='Laszlo Ersek <ler...@redhat.com>' master -- \ ':!OvmfPkg' \ ':!ArmVirtPkg' \ ':!ArmPlatformPkg/ArmVirtualizationPkg' \ | wc -l With master being at a3e25cc8a1dd, that's ~474 commits, out of my ~1266 total. (Those numbers are not precise minimally because, at the start of the git history, while we used SVN, authorship wasn't captured correctly.) IOW, approx. 37 percent of my patches have been for neither OvmfPkg nor ArmVirtPkg. My latest commit that fixes a bug in a core package is five days old (90e11edd16c7, "UefiCpuPkg/PiSmmCpuDxeSmm: fix S3 Resume for CPU hotplug", 2020-03-04). - "mailing list noise": I have processed the complete traffic of the mailing list for 9 years now (not read, but processed). edk2-devel has a low amount of traffic relative to other open source development lists. It is a fraction of qemu-devel, for example. If you see a large OvmfPkg patch series in your list folder, it will say "OvmfPkg" in the blurb subject, and then it takes a single keypress to mark the whole thread read. We could introduce topical mailing lists (different subsystem patches would be CC'd to different lists, but everything would still need to go to the main list as well). - "git repo size": for a current master checkout, OvmfPkg weighs in at 5.5M. In comparison, NetworkPkg is 7.2M, MdePkg is 18M, MdeModulePkg is 27M. Even considering all git objects and such, the repo is not larger than 1.1GiB or so. I assume your platforms must be larger than 5.5M. I'd be happy to have them in the tree. - "git history / commits": they are easy to filter to the packages you care about. We take care not to straddle multiple packages with single commits. May those others in the community please speak up about the burden that OvmfPkg development has subjected them to. > From someone who has developed and maintained platforms with edk2 for > the last decade +, I can tell you that having OVMF in edk2 hasn't kept > the tree free from regressions. Of course. Changes to core packages (even spec changes) are always motivated by platform goals. And regressions are unavoidable, as much as we try to prevent them (even *spec* regressions). I hope you're not claiming that OVMF has been a major source of regressions in the core packages. And, you have the advantage of *plausibly* claiming that OVMF-oriented changes have caused regressions in the core -- plausibly because those contributions, and the dependent OVMF changes, are upstream. Whereas I can't classify any other regressions as associated by Microsoft platform needs, simply because those platform needs have hardly ever been public. (One of my never-ending crusades has been "better commit messages", i.e., with use case spelled out.) > I also don't use it as a source for integration requirements because > it is vastly different than physical platforms and has very little > resemblance to my projects. That's fine. There's a whole bunch of stuff in the tree that's irrelevant to my purposes, I just don't go ahead and claim that they "clutter" the git history for me. - BaseTools -- check. I don't really care about BaseTools internals, I just want them to function OK. In fact, BaseTools used to live outside of the tree, with huge code drops / syncs, and that was no end of misery, for example because it was un-bisectable. (BTW, you are throwing the possibility of bisecting a platform and the core together out the window. Why should any given platform lose this very important trait just because other platforms have never had it, out of their own choice?) - DynamicTablesPkg -- check. No interest, yet it doesn't bother me. - EmulatorPkg, FmpDevicePkg, IntelFsp2Pkg, IntelFsp2WrapperPkg, SignedCapsulePkg, SourceLevelDebugPkg, StandaloneMmPkg, UefiPayloadPkg, UnitTestFrameworkPkg -- check, all irrelevant to me. It's very easy to ignore patches, emails, and discussions around these packages. It's also easy to join them. Even when AppPkg and StdLib were split out to edk2-libc, in <https://bugzilla.tianocore.org/show_bug.cgi?id=1734>, I made the following clear in my agreement: https://edk2.groups.io/g/devel/message/35321 I'm not sure how closely the StdLib internals are tied to day-to-day changes in core edk2; that is, whether we should keep those histories interlinked. That's something for the StdLib maintainers to evaluate. Personally I don't remember many StdLib changes, so there seems to be a genuine separation that supports the new repo idea. I was willing to listen to the StdLib maintainers, if they had wanted to keep the package inside. > I share your concerns about regressions, ease of development, etc. I > want to see tianocore develop workflows and processes that work for > the full community. That means we must take into account the needs of > those that have platforms outside the edk2 repo. We must build tools > that make managing all platforms dependencies tenable. We must create > CI that can leverage a vast number of platforms as an indicator of > breaking changes, yet not be gated on their success. (Side comment: it wasn't me who filed this: <https://bugzilla.tianocore.org/show_bug.cgi?id=2570>.) > We must have a process that lets all interested platforms efficiently > interact with and be part of. The tianocore community is in need of > the larger UEFI ecosystem engagement and we must remove the barriers > to get them involved. I don't want to keep anyone out. I just want to keep OvmfPkg and ArmVirtPkg in. The goals you describe in this paragraph don't conflict with OvmfPkg and ArmVirtPkg, as they are, i.e., in-tree. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55698): https://edk2.groups.io/g/devel/message/55698 Mute This Topic: https://groups.io/mt/71776477/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
