Folks,

Here's the 3rd iteration based on your input.  Please take one last opportunity 
to review, we'll settle on this if there are no major requests by Friday of 
this week.

Problem statement
=================
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.

Proposal
========
1) Create a new repo called edk2-staging
        a) edk2-staging is a fork of edk
        b) edk2-staging/master tracks edk2/master

2) All edk2-staging discussions 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) Request to create a new edk2-staging feature branch sent to 
edk2-devel
        Request should include feature summary, owners, timeline, and quality 
criteria to add to edk2.
        If Request is a platform or package specific feature, pre-approval for 
edk2 trunk promotion may be requested here.
        b) Branch request and branch name must be approved by stewards
        c) Branch maintainer creates edk2-staging feature branch
        d) Branch maintainer creates Readme.MD in root of feature branch with 
summary, owners, timeline, links to related materials.
        e) Branch 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) Patch email send to edk2-devel
        b) Commit message subject format

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

        c) Use same edk2-devel review process 
        d) If pass review, then maintainer commits change to edk2-staging 
feature branch

        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) Request sent to edk2-devel that describes the feature, design, 
testing, etc.
        b) Stewards evaluate request and determine if the feature meets edk2 
criteria.
        c) If approved, use edk2 patch review/commit process on edk2-devel 
mailing list.
        The specific process used to add the feature to edk2 is at the 
discretion of the person doing the merge.
        Some examples are use of 'git rebase' and 'git pull'.  A merge commit 
must always contain the final 'Reviewed-by:' tags.
        d) 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 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) Process 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

</proposal>

BRs,
Tony

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to