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 Tue, 20 Jun 2017 01:02:03 GMT
Perhaps there is a misunderstanding about where a release comes from—master. So any release
tools we have should work fine. It’s just that until you are ready to pull the trigger,
development is in develop or more strictly a “getting a release ready” branch called a
release branch. This sounds like a lot of branches but in practice it’s trivial to merge
and purge. Everything stays clean and rapid fire last minute fixes are isolated to the release
branch before going into master.

The original reason I brought this up is that our Git tools now allow committers to delete
old cruft laden branches that are created and ephemeral with this method. 


On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pat@occamsmachete.com> wrote:

I just heard we are not using git flow (the process not the tool), we are checking unclean
(untested in any significant way) changes to master? What is the develop branch used for?

The master is unstable most all the time with the old method, in fact there is *no stable
bundle of source ever* without git flow. With git flow you can peel off a bug fix and merge
with master and users can pull it expecting that everything else is stable and like the last
build. This has bit me with Mahout in the past as I’m sure it has for everyone. This doesn’t
fix that but it does limit the pain to committers.

If we aren’t going to use it, fine but let’s not agree to it then do something else. If
it’s a matter of timing ok, I understood from Andrew’s mail below there was no timing
issue but I expect there will be Jenkins or Travis issues to iron out.

For reference: http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>
I have never heard of someone who has tried it that didn’t like it but it takes a leap of
faith unless you have git in your bones.


On Apr 22, 2017, at 10:42 AM, Andrew Musselman <andrew.musselman@gmail.com> wrote:

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
View raw message