mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Musselman <andrew.mussel...@gmail.com>
Subject Re: Proposal for changing Mahout's Git branching rules
Date Sat, 22 Apr 2017 17:42:57 GMT
Okay develop it is; I'll cut a develop branch from master right now.

As we go, if people forget and push to master, we can merge those changes
into develop.

In addition, I'm making a 'website' branch for all work on the new version
of the site.

On Sat, Apr 22, 2017 at 10:36 AM, Pat Ferrel <pat@occamsmachete.com> wrote:

> There are tools to implement git-flow that I haven’t used and may have
> some standardization built in but I think “develop” is typical and safe.
>
>
> On Apr 22, 2017, at 10:33 AM, Andrew Musselman <andrew.musselman@gmail.com>
> wrote:
>
> Cool, I'll make a new dev branch now.
>
> Dev, develop, any preference?
>
> On Sat, Apr 22, 2017 at 10:30 AM, Pat Ferrel <pat@occamsmachete.com>
> wrote:
>
> > It hasn't been often but I’ve been bit by it and had to ask users of a
> > dependent project to checkout a specific commit, nasty.
> >
> > The main affect would be to automation efforts that are currently wip.
> >
> > On Apr 22, 2017, at 10:25 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
> > wrote:
> >
> > I've worked in shops where that was the standard flow, in hg or git, and
> it
> > worked great. I'm in favor of it especially as we add contributors and
> make
> > it easier for people to submit new work.
> >
> > Have we had that many times when master got messed up? I don't recall
> more
> > than a few, but in any case the master/dev branch approach is solid.
> >
> > On Sat, Apr 22, 2017 at 10:06 AM, Pat Ferrel <pat@occamsmachete.com>
> > wrote:
> >
> >> I’ve been introduced to what is now being called git-flow, which at it’s
> >> simplest is just a branching strategy with several key benefits. The
> most
> >> important part of it is that the master branch is rock solid all the
> time
> >> because we use the “develop” branch for integrating Jiras, PRs,
> features,
> >> etc. Any “rock solid” bit can be cherry-picked and put into master or
> >> hot-fixes that fix a release but still require a source build.
> >>
> >> Key features of git-flow:
> >> The master becomes stable and can be relied on to be stable. It is
> >> generally equal to the last release with only stable or required
> > exceptions.
> >> Develop is where all the integration and potentially risky work happens.
> >> It is where most PRs are targeted.
> >> A release causes develop to be merged with master and so it maintains
> the
> >> stability of master.
> >>
> >> The benefits of git-flow are more numerous but also seem scary because
> > the
> >> explanation can be complex. I’ve switched all my projects and Apache
> >> PredictionIO is where I was introduced to this, and it is actually quite
> >> easy to manage and collaborate with this model. We just need to take the
> >> plunge by creating a persistent branch in the Apache git repo called
> >> “develop”. From then on all commits will go to “develop” and all PRs
> > should
> >> be created against it. Just after a release is a good time for this.
> >>
> >> https://datasift.github.io/gitflow/IntroducingGitFlow.html <
> >> https://datasift.github.io/gitflow/IntroducingGitFlow.html>
> >>
> >> What say you all?
> >
> >
>
>

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