On 03/15/16 18:20, Kinney, Michael D wrote: > 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 don't object to pulling, if the submitter explicitly requests it, and if we're making this option official now. Regarding Reviewed-by tags, I like to review series per-patch, and I also like the tags to be present in the commit history per-patch. For example, when a series modifies several top-level packages, I don't / can't always review all patches in full depth; so I might give an Acked-by for some patches, or even nothing. In this case I'm fine with the submitter rebasing one last time, adding the tags, and then I can do the pull. (I'll have to remember to verify the individual patches on the branch being pulled, and the labels on the commit messages, against the mailing list traffic.) Thanks Laszlo > > > 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:[email protected]] On Behalf Of David >> Woodhouse >> Sent: Tuesday, March 15, 2016 3:50 AM >> To: Kinney, Michael D <[email protected]>; Mangefeste, Tony >> <[email protected]>; [email protected] <[email protected]> >> 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 > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
