On 2016-03-09 10:53:38, Mangefeste, Tony wrote: > Below are the details of the proposal for a staging branch, please review and > comment. > > <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. >
I think the parts about making a central place for big feature branches seems good. I think Laszlo might have appreciated having a well defined central location for his OVMF SMM enabling branch. I think the processes around allowing the code to be merged seems too heavyweight. In the cases of big patchsets, it can be burdensome enough just to get code review. To insert another process step (and set of approvers) to actually merge the feature seems perhaps unneccesary. > Proposal > ======== > 1) Create a new repo called edk2-staging > a) edk2-staging is a fork of edk > b) edk2-staging/master tracks edk2/master > For branches maintained by package maintainers, could we have them under the edk2 repo and named staging/*? > 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 name]: Subject What about [staging/branch]? > > 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 > b) Branch request and branch name must be approved by stewards Who? > c) Branch maintainer creates edk2-staging feature branch Who would be the maintainer? The submitter, or perhaps a package maintainer that is closely related to the new series. (For example, if it was a series closely related to OVMF, then Laszlo and I would be responsible for the 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 rebased to edk2/master > > 5) Process to update sources in feature branch > a) Patch email send to edk2-devel > b) Commit message subject format > > [staging][branch name][PATCH]: Package/Module: Subject What about [staging/branch PATCH]? (It would work better with git format-patch.) > > 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. > > 5) 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?). > This part seems a bit heavy weight. I think once code has passed review by the package maintainers it should be eligible to be committed to the trunk. Or, is this a process by which the package maintainer may not review the code until this step? -Jordan > 6) 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?). > > 7) 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> > > --- > Tony Mangefeste > Intel Corporation > STO/SMC > Community Technology Lead > Tianocore Community Manager > g+: https://goo.gl/l5B5JH > t: @tonymangefeste > > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
