mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pat Ferrel <...@occamsmachete.com>
Subject Re: Proposal for changing Mahout's Git branching rules
Date Sat, 22 Apr 2017 17:36:09 GMT
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
View raw message