Re: new committer: Dustin Vanstee

please unsubscribe On Wed, Jun 21, 2017 at 6:28 PM, Isabel Drost-Fromm wrote: > Welcome Dustin. Great to have you here. > > Am 20. Juni 2017 23:50:37 MESZ schrieb Trevor Grant < > trevor.d.gr...@gmail.com>: > >The Project Management Committee (PMC) for Apache Mahouthas invited > >Dustin Vanstee

Re: new committer: Dustin Vanstee

Welcome Dustin. Great to have you here. Am 20. Juni 2017 23:50:37 MESZ schrieb Trevor Grant : >The Project Management Committee (PMC) for Apache Mahouthas invited >Dustin Vanstee to become a committer and we are pleased to announce >that he has accepted. > >Dustin has taken superb initiative in th

Re: Proposal for changing Mahout's Git branching rules

So right now, if there was a bug in 0.13.0 that needed an important patch- why not just merge it into master and git branch "branch-0.13.0" On Wed, Jun 21, 2017 at 4:26 PM, Dmitriy Lyubimov wrote: > PS. but i see the rational. to have stable fixes to get into release. > perhaps named release br

Re: Proposal for changing Mahout's Git branching rules

Agreed “ > Given the short nature of the current point release I’d even suggest that > we target putting our decision in practice after the release, which is a > better time to make a change if we are to do so. > “ I bring it up again because the release artifacts listed are more than we have e

[jira] [Commented] (MAHOUT-1988) scala 2.10 is hardcoded somewhere

[ https://issues.apache.org/jira/browse/MAHOUT-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058329#comment-16058329 ] ASF GitHub Bot commented on MAHOUT-1988: GitHub user rawkintrevo opened a pull re

Re: Proposal for changing Mahout's Git branching rules

Which is an option part of git flow but maybe take a look at a better explanation than mine: http://nvie.com/posts/a-successful-git-branching-model/ I still don’t see how this complicates resolving conflicts. It just removes the resoluti

[jira] [Assigned] (MAHOUT-1988) scala 2.10 is hardcoded somewhere

[ https://issues.apache.org/jira/browse/MAHOUT-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Grant reassigned MAHOUT-1988: Assignee: Trevor Grant > scala 2.10 is hardcoded somewhere >

RE: Proposal for changing Mahout's Git branching rules

Pat - I just want to clear one point up.. Trevor volunteering to head up this release and the git-flow plans are independent of each other. The 0.13.1 release was originally planned as a quick follow up to 0.13.0 for each scala/spark conf combo I think this will be 6 artifacts.. spark 1.6.x - 2

Re: Proposal for changing Mahout's Git branching rules

PS. but i see the rational. to have stable fixes to get into release. perhaps named release branches is still a way to go if one cuts them early enough. On Wed, Jun 21, 2017 at 2:25 PM, Dmitriy Lyubimov wrote: > > > On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel wrote: > > Since merges are done by

Re: Proposal for changing Mahout's Git branching rules

On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel wrote: Since merges are done by committers, it’s easy to retarget a contributor’s > PRs but committers would PR against develop, IMO it is anything but easy to resolve conflicts, let alone somebody else's. Spark just asks me to resolve them myself. But

Re: Proposal for changing Mahout's Git branching rules

Since merges are done by committers, it’s easy to retarget a contributor’s PRs but committers would PR against develop, and some projects like PredictionIO make develop the default branch on github so it's the one contributors get by default. In fact this is the primary difference, Master is le

Re: Looking for help with a talk

Isabel, you obviously always can call me with any questions. -D On Sat, May 27, 2017 at 2:01 PM, Isabel Drost-Fromm wrote: > Hi, > > I've been invited to give a machine learning centric keynote at FrOSCon > (free and open source conference, the little sister of FOSDEM, roughly 2500 > attendees o

Re: [DISCUSS] remove getMahoutHome from sparkbindings

i think the idea was that mahout has control over application jars and guarantees that the minimum amount of mahout jars is added to the application. In order to do that, it needs to be able to figure the home (even if it is an uber jar, as some devs have been pushing for for some time now, so it m

Re: new committer: Dustin Vanstee

welcome! On Wed, Jun 21, 2017 at 2:07 PM, Pat Ferrel wrote: > Welcome Dustin! > > Nice work so far, much needed. > > > On Jun 21, 2017, at 12:08 PM, Andrew Palumbo wrote: > > Welcome Dustin! > > > > Sent from my Verizon Wireless 4G LTE smartphone > > > Original message > From:

Re: new committer: Dustin Vanstee

Welcome Dustin! Nice work so far, much needed. On Jun 21, 2017, at 12:08 PM, Andrew Palumbo wrote: Welcome Dustin! Sent from my Verizon Wireless 4G LTE smartphone Original message From: Andrew Musselman Date: 06/20/2017 4:18 PM (GMT-08:00) To: dev@mahout.apache.org Subj

Re: Proposal for changing Mahout's Git branching rules

so people need to make sure their PR merges to develop instead of master? Do they need to PR against develop branch, and if not, who is responsible for confict resolution then that is to arise from diffing and merging into different targets? On Tue, Jun 20, 2017 at 10:09 AM, Pat Ferrel wrote: >

RE: new committer: Dustin Vanstee

Welcome Dustin! Sent from my Verizon Wireless 4G LTE smartphone Original message From: Andrew Musselman Date: 06/20/2017 4:18 PM (GMT-08:00) To: dev@mahout.apache.org Subject: Re: new committer: Dustin Vanstee Welcome Dustin; glad to have you on board! On Tue, Jun 20, 2017