>-----Original Message----- >From: Kubacki, Michael A >Sent: Friday, May 03, 2019 5:16 AM >To: Leif Lindholm <leif.lindh...@linaro.org>; devel@edk2.groups.io >Cc: Gao, Liming <liming....@intel.com>; Andrew Fish <af...@apple.com>; >Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D ><michael.d.kin...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org> >Subject: RE: [edk2-devel] [edk2-platforms] [RFC] Migrate devel-MinPlatform >branch to master branch > >Hi Leif, > >> -----Original Message----- >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >> Sent: Thursday, May 2, 2019 8:04 AM >> To: devel@edk2.groups.io; Kubacki, Michael A >> <michael.a.kuba...@intel.com> >> Cc: Gao, Liming <liming....@intel.com>; Andrew Fish <af...@apple.com>; >> Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D >> <michael.d.kin...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org> >> Subject: Re: [edk2-devel] [edk2-platforms] [RFC] Migrate devel- >MinPlatform >> branch to master branch >> >> Hi Michael, >> >> On Thu, Apr 18, 2019 at 09:11:38PM +0000, Kubacki, Michael A wrote: >> > Hello, >> > >> > This RFC proposes moving the content on the devel-MinPlatform branch >> > in the edk2-platforms repository to the master branch in the >> > edk2-platforms repository. >> > >> > The devel-MinPlatform branch has been used for the initial development >> > of an EDK II based platform design referred to as "Minimum Platform". >> > This design is intended to provide a structured approach to >> > introducing Intel platform code into open source in a consistent manner. >> > >> > For more information about the EDK II Minimum Platform, please refer >> > to the Readme.md in devel-MinPlatform. >> > https://github.com/tianocore/edk2-platforms/blob/devel- >> MinPlatform/Rea >> > dMe.md >> > >> > The following packages would be added in Platform/Intel: >> > * Generic packages: >> > * AdvancedFeaturePkg >> > * MinPlatformPkg >> >> First a generic comment with some examples: >> Both of these include non-architecture-specific components that could be >> useful to have more generally available. >> >> Certainly AdvancedFeaturePkg/Smbios/ and AcpiDebug look like something >> of a generic nature rather than Intel-platform specific. >> >The intention is for advanced features to be generic and architecture >agnostic when possible. We ultimately want to simplify the process to >enable open source edk2 platforms and cross-architecture compatibility >certainly aids in that goal. We're starting with the code in the Intel >directory >and we are open to moving features elsewhere based on interest and >usefulness. > >I suspect we'll also evolve some elements of how these features are >organized and designed based on feedback over time. For example, while >we're starting with one AdvancedFeaturePkg, it may be too monolithic. >More cohesive packages are likely easier to integrate and maintain. So >we may propose breaking this into something like DebugFeaturePkg, >IoFeaturePkg, PowerManagementFeaturePkg, or to some other degree. I >expect the definition to be a fluid process based on actual demand. > >> And Platform/Intel/MinPlatformPkg/Library/CompressLib/CompressLib.c >> appears to have nearly only whitespace differences compared to edk2 >> ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c. >> >> (With edk2 already having 3 additional quite similar files in >> BaseTools/Source/C/Common/EfiCompress.c >> BaseTools/Source/C/Common/TianoCompress.c >> BaseTools/Source/C/TianoCompress/TianoCompress.c) >> >> >That's a good point. In particular, it would be nice to consolidate the code >usage >between ShellPkg and MinPlatformPkg. Perhaps the compression code could >be moved somewhere like MdePkg where it could be used by both packages. > Yes. I will submit BZ for UefiCompressLib usage. And, I will submit another BZ to reduce the duplication compression code in BaseTools.
>> Secondly - edk2 has recently transitioned to bsd+patents license, and it >> would make sense if edk2-platforms did the same. Do we want to do that >> before or after this addition? >> >I will defer this to Mike Kinney. > >> >> Finally, what should we do for Maintainers.txt? >> >I believe we need to have per-package maintainers for the packages being >added. For >example, merge what is in >https://github.com/lgao4/edk2- >platforms/blob/master/Platform/Intel/Maintainers.txt > >I can update the following Maintainers.txt with a proposal. >https://github.com/lgao4/edk2-platforms/blob/master/Maintainers.txt > I think first step is to move the code from branch to master, then update Maintainers.txt to align to edk2 Maintainers.txt. >Regards, >Michael > >> Best Regards, >> >> Leif >> >> > * Board-specific packages: >> > * ClevoOpenBoardPkg >> > * KabylakeOpenBoardPkg >> > * PurleyOpenBoardPkg >> > >> > The following packages would be added in Silicon/Intel: >> > * KabylakeSiliconPkg >> > * LewisburgPkg >> > * PurleyRcPkg >> > * PurleySktPkg >> > >> > The following growth is expected over time: >> > * Platform/Intel - Additional board packages for Intel reference boards >> > including support for some pre-existing product releases >> > * AdvancedFeaturePkg - Additional modular features capable of being >> used >> > in board packages >> > * Silicon/Intel - Additional silicon packages roughly keeping 1:1 parity >> > with board packages >> > >> > We hope the content will enable others to add new board packages and >> > advanced features over time. >> > >> > The result of the change is available here for reference: >> > https://github.com/lgao4/edk2-platforms >> > >> > Regards, >> > Michael >> > >> > >> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40030): https://edk2.groups.io/g/devel/message/40030 Mute This Topic: https://groups.io/mt/31236064/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
