Hello,
We left off with the 3rd draft of the edk2-staging proposal with some really
good feedback. The consistent feedback was to keep any process here simple
and to use features already available from github where it makes sense to do so.
The main purpose of the edk2-staging repo is to provide an area where multiple
developers can collaborate on a complex feature that is not yet ready for
integration into edk2/master. There is no requirement to use edk2-staging.
Developers are welcome us use their own github forks of edk2 to develop a new
feature and discuss it with the edk2 community. If using one specific
developer's
github fork of edk2 becomes cumbersome to manage when multiple developers are
involved, or the ownership of a feature is moving between developers, then
a repo such as edk2-staging that is accessible by all edk2 maintainers may be a
viable option to consider.
With this in mind, I would like to propose that edk2-staging simply be a fork
of edk2 and any maintainer can choose to create a feature branch in edk2-staging
for the purposes of collaboration on that feature.
The active feature branches in edk2-staging may be periodically reviewed to make
sure the feature branches there are under active development and to remove
feature
branches that have been abandoned.
Mixed in the feedback on edk2-staging were requests to support use of pull
requests.
This is an important topic that is also being evaluated, and will be discussed
in
separate RFC email discussions.
Please review the revised proposal below that removes requirements for
approvals to
create/update/remove feature branches in edk2-staging.
<proposal>
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 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
</proposal>
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
