Leif, Have you had a chance to look at this yet? How about a using the name OpenPlatforms as the name of the branch that contains all platforms that are tracking edk2/master, but are not required to be in edk2/master to validate core features?
edk2-platforms/master Tracks edk2/master edk2-platforms/OpenPlatforms Tracks edk2/master and contains edk2-platforms/[branch name] Branch for new platform port or a port that uses a stable edk2/udk release. Thanks, Mike > -----Original Message----- > From: Kinney, Michael D > Sent: Tuesday, May 10, 2016 8:52 AM > To: Leif Lindholm <[email protected]>; Kinney, Michael D > <[email protected]> > Cc: [email protected] > Subject: RE: [edk2] [RFC] EDK2 Platforms Proposal > > 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:[email protected]] > > Sent: Tuesday, May 10, 2016 3:06 AM > > To: Kinney, Michael D <[email protected]> > > Cc: [email protected] > > 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 > > > [email protected] > > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
