We should come to a decision soon on git-flow; a small piece of a conversation between Nikolay and I regarding the CUDA branch and workflow:
nsakharnykh [12:07 PM]

so the plan is to squash CUDA branch and integrate into master? After we check all items in the epic?

apalumbo [5:18 PM]
^^ actually there is still an unresolved question of using git-flow.  If we use that then yes- we'll squash a commit all the current `CUDA` to to `develop` rather than master. we should really we could also just squash and commit our current, inital branch to `CUDA` then to `develop` as MAHOUT-200X, delete the CUDA branch, and continue on from there. with new branches for each issue, MAHOUT-2003, delete the branch upon committing.  this way our work will make it into the nightly SNAPSHOTS.
If we're going to use this, then an 0.13.1-release branch should be created. So that we can check our work into develop as we go.
  --andy

________________________________
From: Andrew Palumbo <[EMAIL PROTECTED]>
Sent: Saturday, July 15, 2017 7:20:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Proposal for changing Mahout's Git branching rules

bumping this thread now that we jave JIRA off this list; also showing an empirical (what I find to be positive)  use-case for Mahout git-flow:
We'd decided to use a git-flow branch management strategy a couple of months back, just before Nikolai and I started working on cuda integration.
At first i was undecided really whether git-flow made sense for a project of our size.. it can take a minute to get used to, and with our multiple repos and forks, I wasn't sure if it really mattered either way.
I created a `git-wip-us.apache.org/mahout/CUDA` feature branch (should have been MAHOUT-2002).  Around that time we found urgent need scala 2.11 and spark > 1.6 capabilities.  I was unable to work on the release at the time and Trevor and Andrew have the release almost down to a few scripts (working from master after I believe decisions swung back to *not* using git-flow).  Trevor is currently running the release, with a code freeze in place, while Nikolay and I can continue to commit to the Feature Branch,  which is not going into the current release.
When CUDA integration is finished, we can merge `git-wip-us.apache.org/mahout/CUDA` into master (develop).
Long story short, A release doesn't have to stop the whole team from working on New Features (slated for later releases).
The couple of issues minor that I see are:
1) If we decide to go with a real git-flow strategy, we should be merging our feature branches into `develop`, which will be  at the least a minor jenkins headache. (we'll need to publish our nightlies off of `develop`).. probably something else Jenkins/hudson related, But Travis has really come a long way in the last year or so, and Trevor recently set it up to test the Spark Module in pseudo-cluster mode.
2) As Dmitriy pointed out, I believe..., unless we can configure  ASF Github to open PRs by default to the `develop` branch, I can almost guarantee that we will have new contributors opening against `master`.
Other than that, I'm not sure of any huge issues or learning curve that we'd need to overcome.
my .02
--andy

________________________________
From: Pat Ferrel <[EMAIL PROTECTED]>
Sent: Friday, June 23, 2017 11:23:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Proposal for changing Mahout's Git branching rules

I don’t know where to start here. Git flow does not address the merge conflict problems you talk about. They have nothing to do with the process and are made no easier or harder by following it.

The only thing I can comment on is that PredictionIO sets “develop” as the default branch so PRs are always against that, making absolutely no difference in convenience to contributors. And since we should soon be able to use the shiny green merge button on github, the process will quite smooth and far less dangerous since master is not affected.

Note that this is from experience, not hypotheticals. PIO has a mess of dependency combinations, even worse than Mahout and we’ve found that following this makes a hard job at least contained. Merging will always be hard but thats why we get the big bucks ;-)

Contributors voted to use the process on PIO just like committers and something like 6 have since graduated to committer status over the last 6 months.

I’d be happy to put anyone in touch with them if you want to see what they think.

On Jun 22, 2017, at 4:21 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:

and contributors convenience should be golden IMO. I remember experiencing
a mild irritation when i was asked to resolve the conflicts on spark prs
because I felt they arose solely because the committer was taking too long
to review my PR and ok it. But if it were resulting from the project not
following simple KISS github PR workflow, it probably would be a bigger
turn-off.

and then imagine the overhead of explaining to every newcomer that they
should and why they should be PRing not against the master but something
else when every other ASF project accepts PRs against master...

I dunno... when working on github, any deviation from github commonly
accepted PR flows imo would be a fatal wound to the process.

On Thu, Jun 22, 2017 at 4:13 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB