public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: "Andrew Fish (afish@apple.com)" <afish@apple.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [RFC V2] EDK2 Platform Proposal
Date: Fri, 14 Oct 2016 13:59:02 +0100	[thread overview]
Message-ID: <20161014125902.GK3471@bivouac.eciton.net> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F564824884@ORSMSX113.amr.corp.intel.com>

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 :)

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.

I currently have no interest in the stable-* branches, but I
completely understand why you need them.

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.

If we cannot agree on the meaning of master, then I would request
another specific branch to fill the function I describe above.

Regards,

Leif

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 <leif.lindholm@linaro.org>; Andrew Fish (afish@apple.com)
> > <afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> > 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 <michael.d.kinney@intel.com>
> > > 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 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.".
> > > >
> > > >
> > > >
> > > > <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.
> > >
> > > 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
> > >
> > > >
> > > >
> > > > </proposal>
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > >
> > > >
> > > > Mike
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > > https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2016-10-14 12:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 20:54 [RFC V2] EDK2 Platform Proposal Kinney, Michael D
2016-09-28 22:22 ` Leif Lindholm
2016-09-28 22:27   ` Andrew Fish
2016-09-29 22:21     ` Kinney, Michael D
2016-09-29 22:15   ` Kinney, Michael D
2016-10-14  7:14   ` Kinney, Michael D
2016-10-14  7:25     ` Kinney, Michael D
2016-10-14 12:59       ` Leif Lindholm [this message]
2016-10-14 15:48         ` Kinney, Michael D
2016-10-05  6:11 ` Bhupesh Sharma
2016-10-05 13:23   ` Richardson, Brian
2016-10-05 14:16   ` Sakar Arora
2016-10-10 19:22     ` Leif Lindholm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161014125902.GK3471@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox