Laszlo, I agree branch maintainer should be able to choose to rebase the branch as needed. Branch maintainers can also create V1, V2, ..., Vn versions of the feature branch as needed.
Advertising features under development in either personal github branches or the Staging branch is important. Wiki is one option. Tony is working on Bugzilla for Tianocore with the ability to add a new feature in Bugzilla. A field in Bugzilla with a pointer to the development branch for a new feature would be another option for everyone to find the active branches for features under development. Davis also suggested use of pull-requests. That is another way a set of features under development can be advertised. I personally would prefer using Bugzilla for bugs and feature tracking with maybe a Wiki page that is auto generated from Bugzilla with the features that are under active development. Mike > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, April 11, 2016 7:42 AM > To: Kinney, Michael D <michael.d.kin...@intel.com> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Mangefeste, Tony > <tony.mangefe...@intel.com> > Subject: Re: [edk2] [RFC] EDK2 Staging Proposal 4th Draft > > On 04/07/16 19:27, Kinney, Michael D wrote: > > 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> > > Sorry for not following up earlier. I think I was mainly lacking a good > use case, especially (as David asked too) what "extra" this staging repo > would provide over personal git repos. > > I think I may have found that "extra", as far as I'm concerned > personally. The bonus is not on the git side of things -- the bonus is > on the mailing list side. Namely, the above enables people to submit > patches against as-yet incomplete features, on the list, for discussion > / review, without confusing maintainers. The separate subject prefix > [staging/branch] would eliminate confusion, in both directions: it > wouldn't mislead maintainers into applying patches to the wrong branch, > and it would also direct interested people to the right branch (because > the branch namespace -- i.e., the staging repo -- would be "central"). > > One thing I believe the proposal should incorporate explicitly: enable > the owner of a given staging branch to rebase it. > > I don't know if github allowed such fine-grained control though! If it > doesn't, then maybe we'll have to work with staging trees, instead of > staging branches. That's almost the same (well, after all, they *are* > the same) as personal repos. To me, that difference doesn't really > matters. What matters are the [staging/branch] subject prefixes. > > If we can get them to uniquely identify either a branch in the central > staging repo, or else a branch in a maintainer's "well-known" personal > repo, then I think the proposal would apply just as well with said > "well-known" personal repos too. The list of "currently alive" staging > trees (with their associated subject prefixes) could be stored on the wiki. > > But, again, the "staging tree" idea is only relevant if github doesn't > allow per-maintainer control (rebase) of a staging branch. > > Thanks > Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
