cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@shapeblue.com>
Subject Re: [DISCUSS] new way of github working
Date Mon, 08 Jan 2018 21:30:11 GMT
Marc-Aurèle and Rafael, I mean both. I know we used to require the first, to create the release
notes in a concise way and we used to ban the other because it leads to unnavigable revision
trees. But now that squash and merge is a functionality of github one might argue that it
doesn’t matter anymore. Personally, I am against squashing persé, in any case. I am not
the law (other than during some triathlons) so we jointly might decide differently.

On 08/01/2018, 16:50, "Nicolas Vazquez" <Nicolas.Vazquez@shapeblue.com> wrote:

    The same as Rafael described. If it is the second case I would prefer rebasing the target
branch and push force instead of including merge commits in a PR
    
    Obtener Outlook para Android<https://aka.ms/ghei36>
    
    ________________________________
    From: williamstevens@gmail.com <williamstevens@gmail.com> on behalf of Will Stevens
<wstevens@cloudops.com>
    Sent: Monday, January 8, 2018 11:34:42 AM
    To: dev@cloudstack.apache.org
    Subject: Re: [DISCUSS] new way of github working
    
    Just a note Daan.  If a PR is merged with the `git pr ####` tool in our
    utilities folder, it will automatically include the merge commit.  Figured
    I should mention that...
    
    *Will Stevens*
    CTO
    
    <https://goo.gl/NYZ8KK>
    
    On Mon, Jan 8, 2018 at 8:26 AM, Marc-Aurèle Brothier <marco@exoscale.ch>
    wrote:
    
    > Same opinion as Rafael described.
    >
    > On Mon, Jan 8, 2018 at 11:30 AM, Rafael Weingärtner <
    > rafaelweingartner@gmail.com> wrote:
    >
    > > I did not fully understand what you meant.
    > >
    > > Are you talking about the merge commit that can be created when a PR is
    > > merged? Or, are you talking about a merge commit that is added to a PR
    > when
    > > a conflict is solved by its author(s)?
    > >
    > >
    > > I do not have problems with the first type of merge commits. However, I
    > > think we should not allow the second type to get into our code base.
    > >
    > > On Mon, Jan 8, 2018 at 7:45 AM, Daan Hoogland <daan.hoogland@gmail.com>
    > > wrote:
    > >
    > > > Devs,
    > > >
    > > > I see a lot of merge master to branch commits appearing on PRs. This is
    > > > against prior (non-hard) agreements on how we work. It is getting to be
    > > the
    > > > daily practice so;
    > > > How do we feel about
    > > > 1. not using merge commits anymore?
    > > > 2. merging back as a way of solving conflicts?
    > > > and
    > > > Do we need to make a policy of it or do we let it evolve, at the risk
    > of
    > > > having more hard to track feature/version matrices?
    > > >
    > > > --
    > > > Daan
    > > >
    > >
    > >
    > >
    > > --
    > > Rafael Weingärtner
    > >
    >
    
    Nicolas.Vazquez@shapeblue.com 
    www.shapeblue.com
    ,   
    @shapeblue
      
     
    
    


daan.hoogland@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Mime
View raw message