Re: Proposal for changing Mahout's Git branching rules

[Andrew Musselman]

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  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 
> 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 
> 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.mussel...@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 
> > 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?
> >
> >
>
>

Re: Proposal for changing Mahout's Git branching rules

[Pat Ferrel]

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  
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  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 
> 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 
> 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?
> 
> 

Re: Proposal for changing Mahout's Git branching rules

[Andrew Musselman]

Cool, I'll make a new dev branch now.

Dev, develop, any preference?

On Sat, Apr 22, 2017 at 10:30 AM, Pat Ferrel  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 
> 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 
> 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?
>
>

Re: Proposal for changing Mahout's Git branching rules

[Pat Ferrel]

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  
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  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?

Re: Proposal for changing Mahout's Git branching rules

[Andrew Musselman]

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  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?

Proposal for changing Mahout's Git branching rules

[Pat Ferrel]

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 


What say you all? 

Re: Welcome New Committer Nikolay Sakharnykh

[Peng Zhang]

Welcome Nikolay.


On Sat, 22 Apr 2017 at 12:17 Andrew Musselman  wrote:

> The Apache Mahout PMC is pleased to announce that we have asked Nikolay
> Sakharnykh to become a committer and he has accepted. His contribution of
> an initial set of CUDA bindings into the project are good progress toward
> our goal of simplifying matrix math at scale.
>
> Being a committer allows you to contribute more easily to the project,
> since in addition to posting pull requests and patches you're also granted
> write access to the code repository; which in turn means you can review and
> accept community contributions, and help others pitch in.
>
> Nikolay, we're looking forward to working with you in the future; welcome!
> It is customary for new committers to introduce themselves with a few words
> :)
>
> Best
> Andrew
>