Leif, You raise some very good concerns. I do not think edk2-platforms is intended to solve all of these, and I agree that a branch per platform can make some things much worse, especially if there are many different core overrides in platform branches.
We need to consider different types of platform ports and figure out the right landing zone for each. 1) Platforms required to validate a core feature in edk2/master 2) Platforms that require a validated/stable release of edk2 3) Platforms that are always synced with edk2/master, but do not improve edk2 core feature coverage. 4) Platforms that are under active initial porting efforts, have stability issues, or code quality issues. edk2/master works for (1) edk2-platforms/<platform branch> works for (2) and (4) As platforms in category (4) mature they migrate into (1), (2), or (3) We do not have a landing zone for (3). Maybe we can have a special branch in edk2-platforms that contains all the platforms in this category, so we can make sure things like common overrides and features common to many different platforms can be easily identified. This special branch can be auto synced to edk2/master so incompatibilities introduced by platform changes or edk2/master changes can be quickly identified. I am looking into a different proposal to add some tree organization to edk2/master. Part of that includes a landing zone for vendor specific UEFI/PI device drivers that can be used by many different platforms. Let's continue to refine the set of proposals here to address all of the important issues you have raised. Best regards, Mike > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Tuesday, May 10, 2016 3:06 AM > To: Kinney, Michael D <michael.d.kin...@intel.com> > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] EDK2 Platforms Proposal > > 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 > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
