After collecting numerous feedback, here's a clean 2nd proposal for review.
* Message format clean
* Approval process updates for stanging -> EDK2 trunk
* The intention of the staging branch is _not_ to work on features that grow to
unreasonable sizes. It is to manage features in an isolated environment that
requires collaboration and testing by the community. The stewards will ensure
that any features that are developed, tested within the staging area are
managed closely, and prevent unmanageable merges.
* Other minor fixes, changes...
Let's drive for closure on this by Tuesday, March 15, 2016. If anyone else
speaks up and needs more time, please speak up, right away.
<proposal>
=========================
edk2-staging Proposal V2
=========================
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
d) Remove feature branch from edk2-staging (maybe archived elsewhere?).
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 (maybe archived elsewhere?).
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
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
