cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: [DISCUSS] new way of github working
Date Mon, 15 Jan 2018 20:14:45 GMT
If the new approach is adopted, we will likely have to change the
functionality of the 'tools' here:
https://github.com/apache/cloudstack/tree/master/tools/git

Especially 'git-pr' creates merges with the "would be deprecated" style, so
we will probably want to adapt our tracked tooling to conform with any new
styles we adopt.

Cheers,

*Will Stevens*
CTO

<https://goo.gl/NYZ8KK>

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

> 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