The ideal is to align to the edk2 project. The next steps that we're working on with Tianocore/edk2 is to define how features bubble up from the main trunk up to the edk2, and ultimately the udk.
We haven't defined or started that discussion yet. I'll plan to roll out more details in the coming weeks. As we get our first staging feature, we can see how it plays out. By the way, the staging area can be used for feature development, it does not imply that all feature development is done in the staging branch. This is just a way to provide an isolated environment for design, validation before merging to the edk2 trunk (or udk I suppose). -----Original Message----- From: Gao, Liming Sent: Monday, March 14, 2016 8:36 AM To: Mangefeste, Tony <[email protected]>; [email protected] <[email protected]> Subject: RE: EDK2 Staging Repository 2nd Draft On edk2-staging, do we need to regularly sync edk2 change into edk2-staging and keep edk2-staging as the mirror of ed2 project? Or align it to edk2 project only when new udk release is made? I think it will be fine to let edk2-staging align to edk2 udk release, not as edk2 mirror. New feature can be developed based on edk2 udk branch, not edk2 master. Thanks Liming -----Original Message----- From: edk2-devel [mailto:[email protected]] On Behalf Of Mangefeste, Tony Sent: Saturday, March 12, 2016 8:26 AM To: [email protected] <[email protected]> Subject: [edk2] EDK2 Staging Repository 2nd Draft Importance: High 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
