David, Thanks for the suggestion. Today the git dev process requires a rebase. Given that this operation is transferring content from one community maintained feature branch in edk2-staging into edk2/master, I agree the option to use 'git pull' should be available. Not sure it should be required in all cases. I would prefer let the feature owner(s) decide which method makes the most sense.
Does anyone have any objections to supporting either the current rebase work flow or a 'git pull' work flow in step (6)? I think there are several methods we can support for development. 1) Simple bug fixes/features sent directly to edk2-devel for PRs. 2) A larger or more complex bug fix/feature can optionally post a link to a branch on personal github fork to help simplify the review process for those reviewers that prefer to use that method. This type of bug fix or feature is usually owned by a single subject matter expert. 3) A larger or more complex feature that requires design/dev/test by more than one subject matter expert. We already support (1) and (2) today. Feature branches on edk2-staging are intended for (3). I can think of a couple ways we end up in (3). The first is a feature we know requires multiple subject matter experts and the request is made to add to edk2-staging from the beginning. The second is a PR that is sent to edk2-devel, and the community believes it needs more design/dev/test work that requires cooperation of multiple subject matter experts and the PR is re-directed to a feature branch in edk2-staging. Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David > Woodhouse > Sent: Tuesday, March 15, 2016 3:50 AM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Mangefeste, Tony > <tony.mangefe...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > Subject: Re: [edk2] EDK2 Staging Repository 2nd Draft > > On Tue, 2016-03-15 at 00:16 +0000, Kinney, Michael D wrote: > > > > > > Can you provide some revised text you would like to see in step 6. > > > > I agree that we need to use the tools in ways that help make this easy, > > prevent > > errors, and preserve history. Given that step 6 describes promoting a > > feature > > from edk2-staging repo to edk2 repo, what set of git operations you would > > recommend? > > Literally, 'git pull'. So my change in patch form would be: > > @@ > 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 > + c) If approved, use 'git pull' to merge the branch into edk2 master, > adding > + any final 'Reviewed-by:' tags to the merge commit as appropriate. > d) Remove feature branch from edk2-staging (maybe archived > elsewhere?). > > > I'm still interested in what benefit we gain from a centralised > edk2-staging repository though, over the normal process of contributors > just pushing their work to github repositories and submitting PRs. > > -- > dwmw2 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
