Hi Mike, Apologies for delay in responding, this was a topic I wanted to leave some time to think about.
On Tue, May 03, 2016 at 04:30:36PM +0000, Kinney, Michael D wrote: > Similar to edk2-staging, we also have a need to manage platforms > that have been ported to edk2. Jordan has created a repository > called edk2-platforms and has created a branch for the > minnowboard-max that uses a validated release of the UDK 2015 for > the dependent packages: > > https://github.com/tianocore/edk2-platforms > > https://github.com/tianocore/edk2-platforms/tree/minnowboard-max-udk2015 > > Instead of creating a branch per feature in edk2-staging, the > proposal is to create a branch per platform in edk2-platforms. The > maintainer(s) that create and support a platform branch can decide > if the platform is synced to edk2/master for dependent packages, or > uses a stable release of the edk2 for dependent packages. > > This proposal provides an area for platform development so we can > minimize the number of platforms that are included in edk2/master. > It is important to keep some platforms in edk2/master so we can use > those platforms to validate features in non-platform packages in > edk2/master. If a new platform does not add feature coverage to > edk2/master, then a new edk2-platforms branch would be recommended. > > Please review the proposal below for edk2-platforms. > > If this proposal is accepted, then a review of the platform in > edk2/master can Be done to see if any of them should be moved to > branches in edk2-platforms. First of all, let me reiterate - I very much want to see more public platform code. To the extent this helps that happen, I am a strong supporter. However, this proposal does not really address the issues I've been pursuing, and am currently staging in my OpenPlatformPkg tree: - The ability to see when a core change breaks some/all platform ports. - The ability to easily spot common code that should be turned into core libraries. - The ability to easily spot near-identical local overrides to common libraries that should turn into options in an existing core library. - The ability to share drivers for common components between different platforms, benefitting from feature additions and bugfixes. It may not be intending to do this, which is fine, but I'd like to share a few warnings - seen both in Linaro's Linux kernel work and in Linaro's UEFI work when the "platform feature branch" approach was used (also try an Internet search for "vendor kernels"): - Keeping each platform port in a separate branch will inevitably lead to incompatible changes to core components. - Some of these changes will be fundamentally incompatible with other platforms, because they were made in complete isolation from those other platforms. - Mandating that all ports are based on a UDK version reduces the scope of these incompatibilities, but ports will inevitably want access to newer features that what is provided in UDK, so will cherry-pick ... and then some will change that. - But EDK2 has reasonably high churn on internal interfaces, and taking the step from one UDK to the next could mean a substantial amount of work at once, instead of progressively adjusting to core changes. (Acknowledging that this may well be preferable for some.) - Preventing this would cause higher maintainer overhead than letting the platforms into the main tree. So I guess my main question is - should this be seen as a complement to what I am looking for, or should I write an alternative proposal trying to incorporate the use-cases this one covers as well as the ones I am looking for? Regards, Leif > <proposal> > > > > Problem statement > ================= > Need place on tianocore.org where platforms can be maintained by the EDK II > community. This serves several purposes: > > * Encourage more platforms sources to be shared earlier in the > development process > * Allow platform sources to be shared that may not yet meet all edk2 > required quality criteria > * Allow platform source to be shared so the EDK II community may > choose to help finish and validate > * Allow more platforms to be used as part of the edk2 validation and > release cycle. > * Not intended to be used for bug fixes. > > > Proposal > ======== > 1) Create a new repo called edk2-platforms > > a) edk2-platforms is a fork of edk2 > > b) edk2-platforms/master tracks edk2/master > > > 2) edk2-platforms discussions can use the existing edk2-devel > mailing list for design/patch/test. > > Use the following style for discussion of a platform branch in > edk2-platforms repo. > > [platforms/branch]: Subject > > > 3) All commits to edk2-platforms must follow same edk2 rules > (e.g. Tiano Contributor's Agreement) > > > 4) Process to add a new platform to edk2-platforms > > a) Maintainer sends patch email to edk2-devel mailing list > announcing the creation of a new platform branch in > edk2-platforms with Readme.MD. Readme.MD is in root of > platform branch with summary, owners, status, build > instructions, target update instructions, OS compatibility, > known issues/limitations, links to related materials, and > anything else a developer would need to use the platform > branch. > > b) Maintainer creates platform branch in edk2-platforms > > c) Maintainer is responsible syncing platform to edk2/master or > supported edk2 branch. > > > 5) Process to update sources in feature branch > > a) Commit message subject format: > > [platforms/branch PATCH]: Package/Module: Subject > > b) Directly commit changes to platform branch or if community > review is desired, then use edk2-devel review process. > > > 7) Process to remove an edk2-platforms branch > > a) Stewards may periodically review of platform branches in > edk2-platforms (once a quarter?) > > b) If no activity for extended period of time and platform is > not being maintained and is no longer functional then > stewards send email to edk2-devel to request deletion of > platform branch. > > c) If no objections from EDK II community, then platform branch > is deleted and archived at > > https://github.com/tianocore/edk2-archive. > > > 8) How to evaluate a platform in edk2-platforms > > a) Clone edk2-platforms/[branch name] > > b) Following instructions in Readme.MD to build firmware and > update target platform > > > </proposal> > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
