cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <raj...@apache.org>
Subject Re: [PROPOSAL] Commit to master through PR only
Date Thu, 02 Jul 2015 03:53:26 GMT
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 <terbolous@gmail.com> wrote:

> On Wed, Jul 1, 2015 at 7:48 PM, Rohit Yadav <rohit.yadav@shapeblue.com>
> wrote:
>
> > Hi,
> >
> > > On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen <runseb@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message