cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: [DISCUSS] new way of github working
Date Mon, 15 Jan 2018 20:06:02 GMT
Daan,

Now that master is open for merges again, can we get a feedback here? It
might be interesting to find a consensus and a standardize way of working
for everybody before we start merging things in master again …



On Mon, Jan 8, 2018 at 8:40 PM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:

> This might be my lack of expertise in Git (Github). I like the merge
> commits (when merging a PR) because I can easily find the date when
> something has been introduced to the code base. Of course, this can also be
> achieved through Jira tickets and Github PRs history. This means I would
> not mind adopting the merge and squash option on Github.
>
> On the other hand, regarding the second issue, I prefer the philosophy of
> single commit PRs; otherwise, it feels pretty hard to track what was
> introduced by a PR then. I recall seeing PRs with 100+ commits laying
> around, and I confess that I cannot find myself in the middle of that
> mayhem..
>
> Daan, could you provide more insights on the benefits of having a commit
> per change in a PR?
>
> On Mon, Jan 8, 2018 at 7:30 PM, Daan Hoogland <daan.hoogland@shapeblue.com
> > wrote:
>
>> 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
>>
>>
>>
>>
>
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner

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