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: user@mahout.apache.org Cc: Mahout Dev List <d...@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

ist <d...@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

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

As I said I was sure there would be Jenkins issues but they must be small since it’s just renaming of target branches. Releases are still made from master so I don’t see the issue there at all. Only intermediate CI tasks are triggered on other branches. But they would have to be in your

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

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

Re: Proposal for changing Mahout's Git branching rules

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

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