From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3732C1A1E9E for ; Fri, 14 Oct 2016 08:49:01 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 14 Oct 2016 08:49:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,493,1473145200"; d="scan'208";a="1053859602" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 14 Oct 2016 08:49:00 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.161]) by ORSMSX107.amr.corp.intel.com ([169.254.1.231]) with mapi id 14.03.0248.002; Fri, 14 Oct 2016 08:49:00 -0700 From: "Kinney, Michael D" To: Leif Lindholm , "Kinney, Michael D" CC: "Andrew Fish (afish@apple.com)" , "edk2-devel@lists.01.org" Thread-Topic: [edk2] [RFC V2] EDK2 Platform Proposal Thread-Index: AdIU6nQzG60V/uVFSPei1E0IX4fvwQFJxZyAAvXh6fAAAJKfoAAagwQAAAjpAEA= Date: Fri, 14 Oct 2016 15:48:59 +0000 Message-ID: References: <20160928222259.GW16080@bivouac.eciton.net> <20161014125902.GK3471@bivouac.eciton.net> In-Reply-To: <20161014125902.GK3471@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2U2MTYzYjItYWQ0OC00Y2ZiLTg2ZWMtNjk0YzE0MjQ4ZjQzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IklEWFNuMDhNXC8rT3JremtET3E5aktNaXAzQ2hzbEJ4TXJ1bmxkSXNxQXVFPSJ9 x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: [RFC V2] EDK2 Platform Proposal X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:49:01 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Leif, That makes sense to me. I will update the Readme.md to cover The edk2-platforms/master branch. If a platform does not want to be maintained on master any=20 longer, it could be moved to a stable-* branch against the most=20 recent UDK20xx branch of edk2. Once a platform is no longer used or maintained at all, then=20 archiving sounds appropriate. Mike > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Friday, October 14, 2016 5:59 AM > To: Kinney, Michael D > Cc: Andrew Fish (afish@apple.com) ; edk2-devel@lists.01.= org > Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal >=20 > So, I don't actually disagree with what you're saying, but I think we > already know that we are looking for different things out of this > repository :) >=20 > This is not a problem, but I do want us to be able to agree on a > wording that works for both of our use-cases. >=20 > I currently have no interest in the stable-* branches, but I > completely understand why you need them. >=20 > I want _lots_ of platforms in master, but I want all of the platforms > in master to be ones that have an active maintainer - and as such will > be fixed up as required when core changes happen. To me, master should > be drinking from the fire hose. But any platforms in master that are > not being kept functional should be moved out and archived. >=20 > If we cannot agree on the meaning of master, then I would request > another specific branch to fill the function I describe above. >=20 > Regards, >=20 > Leif >=20 > On Fri, Oct 14, 2016 at 07:25:19AM +0000, Kinney, Michael D wrote: > > Leif, > > > > I could see edk2-platforms/master being the platform branch that > > contains the set of platforms that are synced with edk2/master and > > are required to be tested when changes are made to edk2/master. > > Or at least guaranteed to be tested when a stable release of > > edk2/master is made. > > > > Similar to what we expect for the platforms in edk2/master such > > as OvmfPkg, EmulatorPkg, and Nt32Pkg. > > > > Given that not everyone would have access to platform targets to > > run tests, the minimum requirement could be build tests. > > > > Mike > > > > > -----Original Message----- > > > From: Kinney, Michael D > > > Sent: Friday, October 14, 2016 12:15 AM > > > To: Leif Lindholm ; Andrew Fish (afish@appl= e.com) > > > ; Kinney, Michael D > > > Cc: edk2-devel@lists.01.org > > > Subject: RE: [edk2] [RFC V2] EDK2 Platform Proposal > > > > > > Leif and Andrew, > > > > > > I have added the content of this proposal to a new Readme.md file in > > > the edk2-platforms/about branch and removed the old README file. > > > > > > https://github.com/tianocore/edk2-platforms/tree/about > > > > > > I have also added a template at the bottom of the process description > > > for a Readme.md that describes multiple platforms with links to a > > > Readme.md in each platform specific subdirectory. > > > > > > I have also addressed the all the feedback from Leif except for > > > adding platforms to edk2-platforms/master. I think platforms > > > should start in an edk2-platforms/devel-* branch and when they > > > become stable move to an edk2-platforms/stable-* branch. Stable > > > branches may support multiple platform. > > > > > > Using this model, there would not be an edk2-platforms/master > > > branch. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > > > > Sent: Wednesday, September 28, 2016 3:23 PM > > > > To: Kinney, Michael D > > > > Cc: edk2-devel@lists.01.org > > > > Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal > > > > > > > > Hi Mike, > > > > > > > > On Thu, Sep 22, 2016 at 08:54:50PM +0000, Kinney, Michael D wrote: > > > > > Hello, > > > > > > > > > > > > > > > > > > > > Here is the V2 version of the proposal for the edk2-platforms rep= o. > > > > > > > > I'm happy with the proposal in this state, but have a few suggested > > > > updates (mostly to clarify that, long term, we expect most platform= s > > > > to exist in master) and a small suggested addition. > > > > > > > > > Changes from V1: > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > * edk2-platform is not a fork of edk2. > > > > > > > > > > * edk2-platforms branches contain CPU, Chipset, SoC, and platform= specific > > > > > > > > > > packages > > > > > > > > > > * edk2-plaforms/master contains all open platforms that are synce= d with > > > > > > > > > > edk2/master. > > > > > > > > > > * Each edk2-platforms branch may support many platforms (not just= one) > > > > > > > > > > * Use PACKAGES_PATH to do builds using packages from multiple rep= ositories > > > > > > > > > > * Update edk2-platforms branch naming to clearly identify platfor= ms that > > > > > > > > > > are considered stable and platforms that are under active devel= opment. > > > > > > > > > > * edk2 developers may be required to verify platforms in edk2-pla= tforms > > > > > > > > > > builds as part of test criteria. Especially platforms that are= intended > > > > > > > > > > to be used with edk2/master in edk2-platforms/stable-* branches= . > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > 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 or set of platforms > > > > > > > > > > in edk2-platforms. The maintainer(s) that create and support a > > > > > > > > > > platform branch can decide if the platform uses edk2/master for > > > > > > > > > > dependent packages, or uses a stable release of the edk2 for depe= ndent > > > > > > > > > > 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 u= se > > > > > > > > > > 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 an edk2-platforms branch would be recommended. > > > > > > > > Suggest: ", then edk2-platforms would be recommended.". > > > > > > > > > > > > > > > > > > > Please review the proposal below for edk2-platforms. > > > > > > > > > > > > > > > > > > > > If this proposal is accepted, then a review of the platforms in > > > > > > > > > > edk2/master can be done to see if any of them should be moved to > > > > > > > > > > branches in edk2-platforms. > > > > > > > > Suggest: "should be moved to edk2-platforms.". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem statement > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > 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 e= dk2 > > > > > > > > > > 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. > > > > > > > > Does this final point still apply, now we're going to be using > > > > PACKAGES_PATH rather than keep rebasing on top of edk2/master? > > > > > > > > > > > > > > > > > > > > > > > > Proposal > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > 1) Create a new repo called edk2-platforms > > > > > > > > > > a) The default branch edk2-platforms/master contains all open > > > > > > > > > > platforms that are actively validated against the packages > > > > > > > > > > in edk2/master. > > > > > > > > > > b) The intent is for packages in edk2-platforms to be CPU, Ch= ipset, > > > > > > > > > > SoC, or platform specific. Drivers that are CPU arch and = platform > > > > > > > > > > agnostic should be put into the edk2 repo. > > > > > > > > > > > > > > > > > > > > 2) edk2-platforms discussions use the edk2-devel mailing list > > > > > > > > > > for design/patch/test using 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 rules use for > > > > > > > > > > commits to edk2 (e.g. Tiano Contributor's Agreement) > > > > > > > > > > > > > > > > > > > > 4) Process to add a new branch to edk2-platforms > > > > > > > > > > > > > > > > > > > > a) Maintainer sends patch email to edk2-devel mailing list > > > > > > > > > > announcing the creation of a new branch in edk2-platforms > > > > > > > > > > with Readme.MD. Readme.MD must be in root of branch with > > > > > > > > > > summary, owners, status, build instructions, target updat= e > > > > > > > > > > instructions, OS compatibility, known issues/limitations, > > > > > > > > > > links to related materials, and anything else a developer > > > > > > > > > > needs to use platform(s) in that branch. > > > > > > > > > > > > > > > > > > > > b) Readme.MD must provide the PACKAGES_PATH setting required = to > > > > > > > > > > build along with the branch names of other repos that pla= tform > > > > > > > > > > requires. This allows a platform developer(s) to use pac= kages > > > > > > > > > > from edk2/master or to use packages from a validates UDK = release > > > > > > > > 'validates' -> 'validated' > > > > > > > > > > > > > > (e.g. edk2/UDK2015). > > > > > > > > > > > > > > > > > > > > c) Maintainer creates branch with Readme.MD in edk2-platform= s > > > > > > > > > > > > > > > > > > > > d) An edk2-platforms branch for platforms under developer us= e the > > > > > > > > 'under development'? > > > > > > > > > following branch naming convention: > > > > > > > > > > edk2-platforms/devel-* > > > > > > > > > > > > > > > > > > > > e) An edk2-platforms branch for stable platforms use the fol= lowing > > > > > > > > > > branch naming convention: > > > > > > > > > > > > > > > > > > > > edk2-platforms/stable-* > > > > > > > > > > > > > > > > > > Do we need a: > > > > --- > > > > X) Process to add platform to master? > > > > a) Maintainer ensures any code conflicts are resolved and merged= to > > > > edk2-platforms/master. > > > > > > > > b) Maintainer sends email request to edk2-devel mailing list > > > > announcing intent to integrate a devel-* branch into master. > > > > > > > > c) Platform is reviewed for maturity, and merged to master when > > > > ready. > > > > > > > > How would we do about Readme.MD on master? > > > > Should it be something added to a common Readme.MD for all platform= s > > > > (sounds like it would expload), or should we simply make it move to > > > > the platform-specific directory? > > > > --- > > > > > > > > > 5) Process to update sources in edk2-platforms branch > > > > > > > > > > > > > > > > > > > > a) Commit message subject format: > > > > > > > > > > > > > > > > > > > > [platforms/branch PATCH]: Package/Module: Subject > > > > > > > > Apologies for the late bikeshedding, but could we do this: > > > > [PATCH][platforms/branch] > > > > instead? > > > > To reduce command line tedium with git format-patch. > > > > > > > > > > > > > > > > > > > b) Directly commit changes to branch or if community review = is desired, > > > > > > > > > > use edk2-devel review process. > > > > > > > > > > > > > > > > > > > > 7) Process to remove an edk2-platforms branch > > > > > > > > > > > > > > > > > > > > a) Stewards may periodically review of branches in edk2-plat= forms > > > > > > > > > > (once a quarter?) > > > > > > > > > > > > > > > > > > > > b) If no activity on a branch for extended period of time an= d the branch > > > > > > > > > > is not being maintained and is no longer functional then = stewards > > > > > > > > > > send email to edk2-devel to request deletion of edk2-plat= forms branch. > > > > > > > > > > > > > > > > > > > > c) If no objections from EDK II community, then branch is de= leted 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 > > > > > > > > Question again about Readme.MD for master branch. > > > > > > > > Regards, > > > > > > > > Leif > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > edk2-devel mailing list > > > > > edk2-devel@lists.01.org > > > > > https://lists.01.org/mailman/listinfo/edk2-devel