I do the same Erik. Sometimes I merge the changes from the authors branch directly without creating a local copy (using the command mentioned in the pull request mail).
+1 on 2 manual reviews per PR irrespective of how trivial it is. -1 on squashed commits. If the author thinks that the change deserves more than one commit, it should be that way. Fast forwarding >1 commits and merging doesnt make any sense. The PR information is lost on all the previous commits except for the one where the PR is mentioned. ~Rajani On Thu, Jul 2, 2015 at 1:13 AM, Erik Weber <terbol...@gmail.com> wrote: > On Wed, Jul 1, 2015 at 7:48 PM, Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > > > Hi, > > > > > On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen <run...@gmail.com> > wrote: > > > > > > A few of us are in Amsterdam at DevOps days. We are chatting about > > release management procedure. > > > Remi is working on a set of principles that he will put on the wiki to > > start a [DISCUSS]. > > > > > > However to get started on the right track. I would like to propose the > > following easy step: > > > > > > Starting Monday June 29th (next monday): > > > > > > - Only commit through PR will land on master (after a minimum of 2 LGTM > > and green Travis results) > > > - Direct commit will be reverted > > > - Any committer can merge the PR. > > > > +1 > > > > I’ve been trying to help close PRs, it was difficult at first but then I > > found some tooling to help me do that. I think it’s certainly do-able > > without investing a lot of effort to do it, perhaps can done everyday or > > every few days in a week. > > > > Some suggestions and comments to improve PR reviewing/merging: > > > > - Let's merge the PR commits in a fast forward way instead of doing a > > branch merge that introduces frivolous merge commits. This is one > approach > > to do quickly and painlessly: > > > > > > > http://blog.remibergsma.com/2015/05/24/accepting-pull-requests-the-easy-way/ > > > > > > I'm no git expert, so I don't know if the downloading of patches and > applying them has any benefits over branch merging, but what I usually do > is this: > > (github is my remote name for the github repo) > > $ git fetch github pull/<PR#>/head:<local branch name> > <review/test locally as needed> > $ git checkout master (or whatever branch you're merging to) > $ git merge <local branch name> > > -- > Erik >
