RE: Proposal for changing Mahout's Git branching rules

+1 Sent from my Verizon Wireless 4G LTE smartphone Original message From: Andrew Musselman <andrew.mussel...@gmail.com> Date: 08/02/2017 3:12 PM (GMT-08:00) To: dev@mahout.apache.org Subject: Re: Proposal for changing Mahout's Git branching rules I'm in favor of k

Re: Proposal for changing Mahout's Git branching rules

t; > > Original message > From: Trevor Grant <trevor.d.gr...@gmail.com> > Date: 07/25/2017 07:38 (GMT-08:00) > To: Mahout Dev List <dev@mahout.apache.org> > Subject: Re: Proposal for changing Mahout's Git branching rules > > > +100 > > &g

RE: Proposal for changing Mahout's Git branching rules

Sent from my Verizon Wireless 4G LTE smartphone Original message From: Trevor Grant <trevor.d.gr...@gmail.com> Date: 07/25/2017 07:38 (GMT-08:00) To: Mahout Dev List <dev@mahout.apache.org> Subject: Re: Proposal for changing Mahout's Git branching rules +100

Re: Proposal for changing Mahout's Git branching rules

Fwiw I agree with D, I just don't have enough experience to state it so eloquently. Pat is really in favor, I've got a bad feeling about it- you expressed my 'bad feeling' perfectly. Even though you aren't contributing as much (code) these days, you're still a very valued member of the

Re: Proposal for changing Mahout's Git branching rules

Guys, as you know, my ability to contribute is very limited lately, so i don't feel like my opinion is worth as much as that of a regular committer or contributor. In the end people who contribute things should decide what works for them. I just put forward a warning that while normally this

Re: Proposal for changing Mahout's Git branching rules

On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel wrote: > 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. > I thought i did

Re: Proposal for changing Mahout's Git branching rules

work into develop as we go. --andy From: Andrew Palumbo <ap@outlook.com> Sent: Saturday, July 15, 2017 7:20:50 PM To: dev@mahout.apache.org Subject: Re: Proposal for changing Mahout's Git branching rules bumping this thread now that we jave JI

Re: Proposal for changing Mahout's Git branching rules

.02 --andy From: Pat Ferrel <p...@occamsmachete.com> Sent: Friday, June 23, 2017 11:23:08 AM To: dev@mahout.apache.org 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

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

Re: Proposal for changing Mahout's Git branching rules

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

Re: Proposal for changing Mahout's Git branching rules

should read And then you will face the dilemma whether to ask people to resolve merge issues w.r.t. *dev* and resubmit against *dev*, which will result to high contribtors' attrition, or resolve them yourself without deep knowledge of the author's intent, which will result in delays and plain

Re: Proposal for changing Mahout's Git branching rules

On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel wrote: > 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

Re: Proposal for changing Mahout's Git branching rules

And all this leads me to think that the concerns/worries may not really be warranted, this process just codifies best practices and adds one new thing, which is “develop’ as the default WIP branch. On Jun 22, 2017, at 10:47 AM, Pat Ferrel wrote: Which translates into

Re: Proposal for changing Mahout's Git branching rules

Which translates into exactly what you suggest if we are maintaining release branches. On Jun 22, 2017, at 10:45 AM, Pat Ferrel wrote: Actually I think git flow would merge it into master and tag it with an annotated tag like “0.13.0.jira-123” to reference the bug fix

Re: Proposal for changing Mahout's Git branching rules

Actually I think git flow would merge it into master and tag it with an annotated tag like “0.13.0.jira-123” to reference the bug fix or some other naming scheme. Since the bug is “important” it is treated like what the blog post calls a “hotfix” so the head of master is still stable with

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

Re: Proposal for changing Mahout's Git branching rules

- Original message From: Dmitriy Lyubimov <dlie...@gmail.com> Date: 06/21/2017 2:06 PM (GMT-08:00) To: u...@mahout.apache.org Cc: Mahout Dev List <dev@mahout.apache.org> Subject: Re: Proposal for changing Mahout's Git branching rules so people need to make sure their PR merge

RE: Proposal for changing Mahout's Git branching rules

t <dev@mahout.apache.org> Subject: 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

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

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

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

Re: Proposal for changing Mahout's Git branching rules

First issue, one does not simply just start using a develop branch. CI only triggers off the 'main' branch, which is master by default. If we move to the way you propose, then we need to file a ticket with INFRA I believe. That can be done, but its not like we just start doing it one day. The

Re: Proposal for changing Mahout's Git branching rules

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

Re: Proposal for changing Mahout's Git branching rules

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*

Re: Proposal for changing Mahout's Git branching rules

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

Re: Proposal for changing Mahout's Git branching rules

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

Re: Proposal for changing Mahout's Git branching rules

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

Proposal for changing Mahout's Git branching rules

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,