This repository is used by EDK II as a staging location for new
features that are not yet ready for inclusion in EDK II.

Introduction
=================
Need place on tianocore.org where new features that are not ready for product 
integration can be checked in for evaluation by the EDK II community prior to 
adding to the edk2 trunk.  This serves several purposes:

* Encourage source code to be shared earlier in the development process
* Allow source code to be shared that does not yet meet all edk2 required quality criteria
* Allow source code to be shared so the EDK II community can help finish and validate new features
* Provide a location to hold new features until they are deemed ready for product integration
* Provide a location to hold new features until there is a natural point in edk2 release cycle to fully validate the new feature.
* Not intended to be used for bug fixes.
* Not intended to be used for small, simple, or low risk features.

Process for creating, using, and maintaining staging efforts
========
[Step 1 is already completed, it is here for documentation purposes; proceed to 2)]
1) Create a new repo called edk2-staging
	a) edk2-staging is a fork of edk2
	b) edk2-staging/master tracks edk2/master

2) edk2-staging discussions can use the existing edk2-devel mailing list for design/patch/test.
	Use the following style for discussion of a specific feature branch in edk2-staging repo.

	[staging/branch]: Subject

3) All commits to edk2-staging must follow same edk2 rules (e.g. Tiano Contributor's Agreement)

4) Process to add a new feature to edk2-staging
	a) Maintainer sends patch email to edk2-devel mailing list announcing the creation of a new 
        feature branch in edk2-staging with Readme.MD.  Readme.MD is in root of feature branch 
        with summary, owners, timeline, links to related materials.
	b) Maintainer creates feature branch in edk2-staging
	c) Maintainer is responsible for making sure feature is frequently synced to edk2/master

     NOTE: Feature branch may initially use a stable edk2 tag.  As feature stabilizes, 
           syncs to edk2/master can begin.

5) Process to update sources in feature branch
	a) Commit message subject format:

		[staging/branch PATCH]: Package/Module: Subject

	b) Directly commit changes to feature branch or if community review is desired,
        then use edk2-devel review process.

	NOTE: win32 binaries are not automatically generated if a feature branch includes BaseTools source changes.

6) Process to promote an edk2-staging branch to edk2 trunk
	a) Use edk2 patch review/commit process on edk2-devel mailing list.
        The specific git actions used to add the feature to edk2 is at the discretion 
        of the maintainer(s) doing the merge.  A merge commit must always contain the final
        'Reviewed-by:' tags.
	b) Remove feature branch from edk2-staging and archive at https://github.com/tianocore/edk2-archive.

7) Process to remove an edk2-staging branch
	a) Stewards may periodically review of feature branches in edk2-staging (once a quarter?)
	b) If no activity for extended period of time and feature is no longer deemed a candidate 
        for edk2 then stewards send email to edk2-devel to request deletion of feature branch.  
	c) If no objections from EDK II community, then feature branch is deleted and archived at
        https://github.com/tianocore/edk2-archive.

8) How to evaluate a feature in edk2-staging
	a) Clone edk2
	b) Create local branch with optional platform packages
	c) Build platform in local branch and verify it is stable
	d) Clone edk2-staging/[branch name]
	e) Create local branch with optional platform packages
	f) Build platform in local branch and evaluate new feature