Jordan, Responses included below.
Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan > Justen > Sent: Wednesday, March 9, 2016 1:47 PM > To: Mangefeste, Tony <tony.mangefe...@intel.com>; edk2-devel@lists.01.org > Subject: Re: [edk2] EDK2 Staging Repository > > 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/*? Do you mean a directory in the edk2 repo called staging? I did think about this option, but I am concerned about code that is not ready for product integration being in the edk2 repo and I am also concerned about the size of the edk2 repo. Creating a new repo that is a fork of edk2 addressed both of those issues. > > > 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]? This is a good suggestion and aligned with your comment below on patch email format that works with git. > > > > > 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? See other email from Tony. > > > 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.) Yes. Every new feature that is accepted requires one of the Package Maintainers to be the sponsor for the feature and perform the branch level maintenance actions. > > > 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.) That is a very good suggestion. > > > > > 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 > Package maintainers are involved in the code review of all patches in the edk2-staging repo, so they have already looked at the code. When the maintainer thinks it is ready for the edk2 trunk, then the idea is that submission of major features may need to be scheduled based on other feature integration, current stability of edk2 trunk, and the current point in the edk2 release cycle. So some features may be held temporarily even if they are considered 100% ready. These are some of the reasons for the additional approval steps. Do you have suggestions on how to make it lighter weight? > > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
