From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1ECAD1A1E24 for ; Wed, 28 Sep 2016 15:23:04 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id l132so261699991wmf.0 for ; Wed, 28 Sep 2016 15:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AC4f1OL6b7IqoVs+gCSfGoPgLKptzT3Ane4nzkKJK84=; b=PXQdz2Mrcidmnn7bWcahHybyoTZJgUmPbfWMLsk9uRKPUeRVfsv9qT8dw1vaIJdhPA i+HYAAKMvViAXKWPeNCBDDxSBo0wOu73j4Ta8CMBaclnJogVNS4Ssl70ZNghmIoV5YRO eH6u7WcZFC5CZgMpBo6PsbmEC8EMHO++JtDLo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AC4f1OL6b7IqoVs+gCSfGoPgLKptzT3Ane4nzkKJK84=; b=HS+tHxgRTpy9GBUb4WS8Q50qeZVmJSsctWxH5iNZcLRojzFyV5r+KqZAp71Qj1lNaS 1p6dzwE+ISEH94AAYdMjmr0dK4BNyNJgtvsPyHgU76Q3Cm4mB0pbNwv4ogfnMQLh+4pr vCIh6SuTtg88Eiux9KHyzFnoAL6LOOYST1l66UQM5DMVluVSDx9n6iMraJ15uvXowCc4 dJE5ydLFY1rVOuFzSpxgs/JvOnCbjhLE9XDU/TwrIx6v9Eo2kvP7aJYkez6kxCU5a/FL YtTGDa/ZKObkT1F9Vpm4qH7CnuJypFR5UWq6IMMJbqVQnYH5uRWcNkhDY1Jj3B0ylGem en2g== X-Gm-Message-State: AA6/9Rkr0z0p3KI6YE6LIxfNp2OiiZDSh6ZaIWYRJ9KspRlDs0Zapx9yQup+V+4rIizhRhwJ X-Received: by 10.28.31.76 with SMTP id f73mr9493034wmf.90.1475101382174; Wed, 28 Sep 2016 15:23:02 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id a3sm10595325wjg.33.2016.09.28.15.23.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 15:23:01 -0700 (PDT) Date: Wed, 28 Sep 2016 23:22:59 +0100 From: Leif Lindholm To: "Kinney, Michael D" Cc: "edk2-devel@lists.01.org" Message-ID: <20160928222259.GW16080@bivouac.eciton.net> References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 28 Sep 2016 22:23:04 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 repo. I'm happy with the proposal in this state, but have a few suggested updates (mostly to clarify that, long term, we expect most platforms to exist in master) and a small suggested addition. > Changes from V1: > > ================ > > * 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 synced with > > edk2/master. > > * Each edk2-platforms branch may support many platforms (not just one) > > * Use PACKAGES_PATH to do builds using packages from multiple repositories > > * Update edk2-platforms branch naming to clearly identify platforms that > > are considered stable and platforms that are under active development. > > * edk2 developers may be required to verify platforms in edk2-platforms > > builds as part of test criteria. Especially platforms that are intended > > to be used with edk2/master in edk2-platforms/stable-* branches. > > > > ================= > > > > 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 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 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 > > ================= > > 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. 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 > > ======== > > 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, Chipset, > > 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 update > > 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 platform > > requires. This allows a platform developer(s) to use packages > > 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-platforms > > > > d) An edk2-platforms branch for platforms under developer use the 'under development'? > following branch naming convention: > > edk2-platforms/devel-* > > > > e) An edk2-platforms branch for stable platforms use the following > > 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 platforms (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-platforms > > (once a quarter?) > > > > b) If no activity on a branch for extended period of time and the branch > > is not being maintained and is no longer functional then stewards > > send email to edk2-devel to request deletion of edk2-platforms branch. > > > > c) If no objections from EDK II community, then 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 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