You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mahout.apache.org by Pat Ferrel <pa...@occamsmachete.com> on 2017/04/22 17:06:45 UTC
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, 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 ever done before and the current process does not seem to support this complexity.
On Jun 21, 2017, at 2:37 PM, Andrew Palumbo <ap...@outlook.com> wrote:
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.1.x for scala 2.11 and scala 2.10. we'd hoped it would be straightforward and it was something almost automatable.
The git-flow change idea was floated by you, i believe you around the same time (correct me if I'm wrong.. this was all happening while I was sick). I agree that it should be a team decision, but it also might take some time to transition.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Dmitriy Lyubimov <dl...@gmail.com>
Date: 06/21/2017 2:06 PM (GMT-08:00)
To: user@mahout.apache.org
Cc: Mahout Dev List <de...@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 and merging into
different targets?
On Tue, Jun 20, 2017 at 10:09 AM, Pat Ferrel <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
>> 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 like a lot of branches but in practice it’s trivial to merge and
>> purge. Everything stays clean and rapid fire last minute fixes are
> isolated
>> to the release branch before going into master.
>>
>> The original reason I brought this up is that our Git tools now allow
>> committers to delete old cruft laden branches that are created and
>> ephemeral with this method.
>>
>>
>> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>>
>> 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* without git flow. With git
> flow
>> you can peel off a bug fix and merge with master and users can pull it
>> expecting that everything else is stable and like the last build. This
> has
>> bit me with Mahout in the past as I’m sure it has for everyone. This
>> doesn’t fix that but it does limit the pain to committers.
>>
>> If we aren’t going to use it, fine but let’s not agree to it then do
>> something else. If it’s a matter of timing ok, I understood from Andrew’s
>> mail below there was no timing issue but I expect there will be Jenkins
> or
>> Travis issues to iron out.
>>
>> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
>> http://nvie.com/posts/a-successful-git-branching-model/> I have never
>> heard of someone who has tried it that didn’t like it but it takes a leap
>> of faith unless you have git in your bones.
>>
>>
>> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
>> wrote:
>>
>> 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 <pa...@occamsmachete.com>
>> 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 <
>> andrew.musselman@gmail.com>
>>> 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 <pa...@occamsmachete.com>
>>> 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.musselman@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 <pa...@occamsmachete.com>
>>>> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 ever done before and the current process does not seem to support this complexity.
On Jun 21, 2017, at 2:37 PM, Andrew Palumbo <ap...@outlook.com> wrote:
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.1.x for scala 2.11 and scala 2.10. we'd hoped it would be straightforward and it was something almost automatable.
The git-flow change idea was floated by you, i believe you around the same time (correct me if I'm wrong.. this was all happening while I was sick). I agree that it should be a team decision, but it also might take some time to transition.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Dmitriy Lyubimov <dl...@gmail.com>
Date: 06/21/2017 2:06 PM (GMT-08:00)
To: user@mahout.apache.org
Cc: Mahout Dev List <de...@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 and merging into
different targets?
On Tue, Jun 20, 2017 at 10:09 AM, Pat Ferrel <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
>> 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 like a lot of branches but in practice it’s trivial to merge and
>> purge. Everything stays clean and rapid fire last minute fixes are
> isolated
>> to the release branch before going into master.
>>
>> The original reason I brought this up is that our Git tools now allow
>> committers to delete old cruft laden branches that are created and
>> ephemeral with this method.
>>
>>
>> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>>
>> 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* without git flow. With git
> flow
>> you can peel off a bug fix and merge with master and users can pull it
>> expecting that everything else is stable and like the last build. This
> has
>> bit me with Mahout in the past as I’m sure it has for everyone. This
>> doesn’t fix that but it does limit the pain to committers.
>>
>> If we aren’t going to use it, fine but let’s not agree to it then do
>> something else. If it’s a matter of timing ok, I understood from Andrew’s
>> mail below there was no timing issue but I expect there will be Jenkins
> or
>> Travis issues to iron out.
>>
>> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
>> http://nvie.com/posts/a-successful-git-branching-model/> I have never
>> heard of someone who has tried it that didn’t like it but it takes a leap
>> of faith unless you have git in your bones.
>>
>>
>> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
>> wrote:
>>
>> 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 <pa...@occamsmachete.com>
>> 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 <
>> andrew.musselman@gmail.com>
>>> 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 <pa...@occamsmachete.com>
>>> 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.musselman@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 <pa...@occamsmachete.com>
>>>> 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
Posted by Andrew Palumbo <ap...@outlook.com>.
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.1.x for scala 2.11 and scala 2.10. we'd hoped it would be straightforward and it was something almost automatable.
The git-flow change idea was floated by you, i believe you around the same time (correct me if I'm wrong.. this was all happening while I was sick). I agree that it should be a team decision, but it also might take some time to transition.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Dmitriy Lyubimov <dl...@gmail.com>
Date: 06/21/2017 2:06 PM (GMT-08:00)
To: user@mahout.apache.org
Cc: Mahout Dev List <de...@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 and merging into
different targets?
On Tue, Jun 20, 2017 at 10:09 AM, Pat Ferrel <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> > 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 like a lot of branches but in practice it’s trivial to merge and
> > purge. Everything stays clean and rapid fire last minute fixes are
> isolated
> > to the release branch before going into master.
> >
> > The original reason I brought this up is that our Git tools now allow
> > committers to delete old cruft laden branches that are created and
> > ephemeral with this method.
> >
> >
> > On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> >
> > 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* without git flow. With git
> flow
> > you can peel off a bug fix and merge with master and users can pull it
> > expecting that everything else is stable and like the last build. This
> has
> > bit me with Mahout in the past as I’m sure it has for everyone. This
> > doesn’t fix that but it does limit the pain to committers.
> >
> > If we aren’t going to use it, fine but let’s not agree to it then do
> > something else. If it’s a matter of timing ok, I understood from Andrew’s
> > mail below there was no timing issue but I expect there will be Jenkins
> or
> > Travis issues to iron out.
> >
> > For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> > http://nvie.com/posts/a-successful-git-branching-model/> I have never
> > heard of someone who has tried it that didn’t like it but it takes a leap
> > of faith unless you have git in your bones.
> >
> >
> > On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
> > wrote:
> >
> > 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 <pa...@occamsmachete.com>
> > 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 <
> > andrew.musselman@gmail.com>
> >> 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 <pa...@occamsmachete.com>
> >> 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.musselman@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 <pa...@occamsmachete.com>
> >>> 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
Posted by Andrew Palumbo <ap...@outlook.com>.
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 <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 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 <pa...@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 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 <dl...@gmail.com> 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 <dl...@gmail.com> wrote:
> 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 errors.
>
> On Thu, Jun 22, 2017 at 2:48 PM, Dmitriy Lyubimov <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <pa...@occamsmachete.com>
>> 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-succes
>>> sful-git-branching-model/ <http://nvie.com/posts/a-succe
>>> ssful-git-branching-model/>
>>>
>>> I still don’t see how this complicates resolving conflicts. It just
>>> removes the resolution from being a blocker. If some conflict is pushed to
>>> master the project is dead until it is resolved (how often have we seen
>>> this?)
>>
>>
>> This is completely detached from github reality.
>>
>> In this model, all contributors work actually on the same branch. In
>> github, every contributor will fork off their own dev branch.
>>
>> In this model, people start with a fork off the dev branch and push to
>> dev branch. In github, a contributor will fork off the master branch and
>> will PR against master branch. This is default behavior and my gut feeling
>> no amount of forewarning is going to change that w.r.t. contributors. And
>> if one starts off his/her work with the branch with intent to commit to
>> another, then conflict is guaranteed every time he or she changes the file
>> that has been changed on the branch to be merged to.
>>
>> For example:
>> Master is at A
>> Dev branch is at A - B -C ... F.
>>
>> if I start working at master (A) then i wil generate conflicts if i have
>> changed same files (lines) as in B, C, .. or F.
>>
>> If I start working at dev (F) then i will not have a chance to generate
>> conflicts with B,C,..F but only with commits that happened after i had
>> started.
>>
>> Also, if I start working at master (A) then github flow will suggest me
>> to merge into master during PR. I guarantee 100% of first time PRs will
>> trip on that in github. even if you put "start your work off dev not
>> master" 20 times into project readme.
>>
>> And then you will face the dilemma whether to ask people to resolve merge
>> issues w.r.t. master and resubmit, 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 errors.
>>
>> -d
>>
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Andrew Palumbo <ap...@outlook.com>.
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 <pa...@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 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 <dl...@gmail.com> 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 <dl...@gmail.com> wrote:
> 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 errors.
>
> On Thu, Jun 22, 2017 at 2:48 PM, Dmitriy Lyubimov <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <pa...@occamsmachete.com>
>> 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-succes
>>> sful-git-branching-model/ <http://nvie.com/posts/a-succe
>>> ssful-git-branching-model/>
>>>
>>> I still don’t see how this complicates resolving conflicts. It just
>>> removes the resolution from being a blocker. If some conflict is pushed to
>>> master the project is dead until it is resolved (how often have we seen
>>> this?)
>>
>>
>> This is completely detached from github reality.
>>
>> In this model, all contributors work actually on the same branch. In
>> github, every contributor will fork off their own dev branch.
>>
>> In this model, people start with a fork off the dev branch and push to
>> dev branch. In github, a contributor will fork off the master branch and
>> will PR against master branch. This is default behavior and my gut feeling
>> no amount of forewarning is going to change that w.r.t. contributors. And
>> if one starts off his/her work with the branch with intent to commit to
>> another, then conflict is guaranteed every time he or she changes the file
>> that has been changed on the branch to be merged to.
>>
>> For example:
>> Master is at A
>> Dev branch is at A - B -C ... F.
>>
>> if I start working at master (A) then i wil generate conflicts if i have
>> changed same files (lines) as in B, C, .. or F.
>>
>> If I start working at dev (F) then i will not have a chance to generate
>> conflicts with B,C,..F but only with commits that happened after i had
>> started.
>>
>> Also, if I start working at master (A) then github flow will suggest me
>> to merge into master during PR. I guarantee 100% of first time PRs will
>> trip on that in github. even if you put "start your work off dev not
>> master" 20 times into project readme.
>>
>> And then you will face the dilemma whether to ask people to resolve merge
>> issues w.r.t. master and resubmit, 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 errors.
>>
>> -d
>>
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Trevor Grant <tr...@gmail.com>.
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 community- and I think I speak for most when I
say, your guidance and involvement on the mailing lists is still very
appreciated. Please always feel encouraged to chime in.
my .02
#communityovercode
On Thu, Jul 20, 2017 at 6:46 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
> 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 workflow would not be
> a problem IF people are aware of the flow and start their work off the dev
> branch, based on my git/github experience, a newbie WILL fork from master
> to a private PR branch of her/his own to commence contribution work.
>
> Which, according to proposed scheme, WILL be quite behind the dev branch
> that she will then be asked to merge to.
>
> Which WILL catch the unsuspecting contributor unawares. They will find
> they'd have a significant divergence to overcome in order to attain the
> mergeability of their work.
>
> On Thu, Jul 20, 2017 at 9:06 AM, Dmitriy Lyubimov <dl...@gmail.com>
> wrote:
>
> >
> >
> > On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel <pa...@occamsmachete.com>
> 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 demonstrate that it does make conflicts much more
> probable
> > per below. The point where you start your work and point where you merge
> it
> > do matter. This process does increase the gap between those (which
> implies
> > higher chance of conflicts and deeper divergence from the start). This is
> > is the same reason why people try to merge most recent commit stack back
> as
> > often as possible.
> >
> >
> >>
> >> >> For example:
> >> >> Master is at A
> >> >> Dev branch is at A - B -C ... F.
> >> >>
> >> >> if I start working at master (A) then i wil generate conflicts if i
> >> have
> >> >> changed same files (lines) as in B, C, .. or F.
> >> >>
> >> >> If I start working at dev (F) then i will not have a chance to
> generate
> >> >> conflicts with B,C,..F but only with commits that happened after i
> had
> >> >> started.
> >> >>
> >> >> Also, if I start working at master (A) then github flow will suggest
> me
> >> >> to merge into master during PR. I guarantee 100% of first time PRs
> >> will
> >> >> trip on that in github. even if you put "start your work off dev not
> >> >> master" 20 times into project readme.
> >> >>
> >> >> And then you will face the dilemma whether to ask people to resolve
> >> merge
> >> >> issues w.r.t. master and resubmit, 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 errors.
> >> >>
> >> >> -d
> >> >>
> >> >
> >> >
> >>
> >>
> >
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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 workflow would not be
a problem IF people are aware of the flow and start their work off the dev
branch, based on my git/github experience, a newbie WILL fork from master
to a private PR branch of her/his own to commence contribution work.
Which, according to proposed scheme, WILL be quite behind the dev branch
that she will then be asked to merge to.
Which WILL catch the unsuspecting contributor unawares. They will find
they'd have a significant divergence to overcome in order to attain the
mergeability of their work.
On Thu, Jul 20, 2017 at 9:06 AM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
>
>
> On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel <pa...@occamsmachete.com> 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 demonstrate that it does make conflicts much more probable
> per below. The point where you start your work and point where you merge it
> do matter. This process does increase the gap between those (which implies
> higher chance of conflicts and deeper divergence from the start). This is
> is the same reason why people try to merge most recent commit stack back as
> often as possible.
>
>
>>
>> >> For example:
>> >> Master is at A
>> >> Dev branch is at A - B -C ... F.
>> >>
>> >> if I start working at master (A) then i wil generate conflicts if i
>> have
>> >> changed same files (lines) as in B, C, .. or F.
>> >>
>> >> If I start working at dev (F) then i will not have a chance to generate
>> >> conflicts with B,C,..F but only with commits that happened after i had
>> >> started.
>> >>
>> >> Also, if I start working at master (A) then github flow will suggest me
>> >> to merge into master during PR. I guarantee 100% of first time PRs
>> will
>> >> trip on that in github. even if you put "start your work off dev not
>> >> master" 20 times into project readme.
>> >>
>> >> And then you will face the dilemma whether to ask people to resolve
>> merge
>> >> issues w.r.t. master and resubmit, 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 errors.
>> >>
>> >> -d
>> >>
>> >
>> >
>>
>>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel <pa...@occamsmachete.com> 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 demonstrate that it does make conflicts much more probable
per below. The point where you start your work and point where you merge it
do matter. This process does increase the gap between those (which implies
higher chance of conflicts and deeper divergence from the start). This is
is the same reason why people try to merge most recent commit stack back as
often as possible.
>
> >> For example:
> >> Master is at A
> >> Dev branch is at A - B -C ... F.
> >>
> >> if I start working at master (A) then i wil generate conflicts if i have
> >> changed same files (lines) as in B, C, .. or F.
> >>
> >> If I start working at dev (F) then i will not have a chance to generate
> >> conflicts with B,C,..F but only with commits that happened after i had
> >> started.
> >>
> >> Also, if I start working at master (A) then github flow will suggest me
> >> to merge into master during PR. I guarantee 100% of first time PRs will
> >> trip on that in github. even if you put "start your work off dev not
> >> master" 20 times into project readme.
> >>
> >> And then you will face the dilemma whether to ask people to resolve
> merge
> >> issues w.r.t. master and resubmit, 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 errors.
> >>
> >> -d
> >>
> >
> >
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <dl...@gmail.com> 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 <dl...@gmail.com> wrote:
> 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 errors.
>
> On Thu, Jun 22, 2017 at 2:48 PM, Dmitriy Lyubimov <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <pa...@occamsmachete.com>
>> 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-succes
>>> sful-git-branching-model/ <http://nvie.com/posts/a-succe
>>> ssful-git-branching-model/>
>>>
>>> I still don’t see how this complicates resolving conflicts. It just
>>> removes the resolution from being a blocker. If some conflict is pushed to
>>> master the project is dead until it is resolved (how often have we seen
>>> this?)
>>
>>
>> This is completely detached from github reality.
>>
>> In this model, all contributors work actually on the same branch. In
>> github, every contributor will fork off their own dev branch.
>>
>> In this model, people start with a fork off the dev branch and push to
>> dev branch. In github, a contributor will fork off the master branch and
>> will PR against master branch. This is default behavior and my gut feeling
>> no amount of forewarning is going to change that w.r.t. contributors. And
>> if one starts off his/her work with the branch with intent to commit to
>> another, then conflict is guaranteed every time he or she changes the file
>> that has been changed on the branch to be merged to.
>>
>> For example:
>> Master is at A
>> Dev branch is at A - B -C ... F.
>>
>> if I start working at master (A) then i wil generate conflicts if i have
>> changed same files (lines) as in B, C, .. or F.
>>
>> If I start working at dev (F) then i will not have a chance to generate
>> conflicts with B,C,..F but only with commits that happened after i had
>> started.
>>
>> Also, if I start working at master (A) then github flow will suggest me
>> to merge into master during PR. I guarantee 100% of first time PRs will
>> trip on that in github. even if you put "start your work off dev not
>> master" 20 times into project readme.
>>
>> And then you will face the dilemma whether to ask people to resolve merge
>> issues w.r.t. master and resubmit, 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 errors.
>>
>> -d
>>
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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 <dl...@gmail.com> wrote:
> 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 errors.
>
> On Thu, Jun 22, 2017 at 2:48 PM, Dmitriy Lyubimov <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <pa...@occamsmachete.com>
>> 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-succes
>>> sful-git-branching-model/ <http://nvie.com/posts/a-succe
>>> ssful-git-branching-model/>
>>>
>>> I still don’t see how this complicates resolving conflicts. It just
>>> removes the resolution from being a blocker. If some conflict is pushed to
>>> master the project is dead until it is resolved (how often have we seen
>>> this?)
>>
>>
>> This is completely detached from github reality.
>>
>> In this model, all contributors work actually on the same branch. In
>> github, every contributor will fork off their own dev branch.
>>
>> In this model, people start with a fork off the dev branch and push to
>> dev branch. In github, a contributor will fork off the master branch and
>> will PR against master branch. This is default behavior and my gut feeling
>> no amount of forewarning is going to change that w.r.t. contributors. And
>> if one starts off his/her work with the branch with intent to commit to
>> another, then conflict is guaranteed every time he or she changes the file
>> that has been changed on the branch to be merged to.
>>
>> For example:
>> Master is at A
>> Dev branch is at A - B -C ... F.
>>
>> if I start working at master (A) then i wil generate conflicts if i have
>> changed same files (lines) as in B, C, .. or F.
>>
>> If I start working at dev (F) then i will not have a chance to generate
>> conflicts with B,C,..F but only with commits that happened after i had
>> started.
>>
>> Also, if I start working at master (A) then github flow will suggest me
>> to merge into master during PR. I guarantee 100% of first time PRs will
>> trip on that in github. even if you put "start your work off dev not
>> master" 20 times into project readme.
>>
>> And then you will face the dilemma whether to ask people to resolve merge
>> issues w.r.t. master and resubmit, 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 errors.
>>
>> -d
>>
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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 errors.
On Thu, Jun 22, 2017 at 2:48 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
>
>
> On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <pa...@occamsmachete.com> 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-succes
>> sful-git-branching-model/ <http://nvie.com/posts/a-succe
>> ssful-git-branching-model/>
>>
>> I still don’t see how this complicates resolving conflicts. It just
>> removes the resolution from being a blocker. If some conflict is pushed to
>> master the project is dead until it is resolved (how often have we seen
>> this?)
>
>
> This is completely detached from github reality.
>
> In this model, all contributors work actually on the same branch. In
> github, every contributor will fork off their own dev branch.
>
> In this model, people start with a fork off the dev branch and push to dev
> branch. In github, a contributor will fork off the master branch and will
> PR against master branch. This is default behavior and my gut feeling no
> amount of forewarning is going to change that w.r.t. contributors. And if
> one starts off his/her work with the branch with intent to commit to
> another, then conflict is guaranteed every time he or she changes the file
> that has been changed on the branch to be merged to.
>
> For example:
> Master is at A
> Dev branch is at A - B -C ... F.
>
> if I start working at master (A) then i wil generate conflicts if i have
> changed same files (lines) as in B, C, .. or F.
>
> If I start working at dev (F) then i will not have a chance to generate
> conflicts with B,C,..F but only with commits that happened after i had
> started.
>
> Also, if I start working at master (A) then github flow will suggest me to
> merge into master during PR. I guarantee 100% of first time PRs will trip
> on that in github. even if you put "start your work off dev not master" 20
> times into project readme.
>
> And then you will face the dilemma whether to ask people to resolve merge
> issues w.r.t. master and resubmit, 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 errors.
>
> -d
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <pa...@occamsmachete.com> 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/ <http://nvie.com/posts/a-successful-git-branching-model/>
>
> I still don’t see how this complicates resolving conflicts. It just
> removes the resolution from being a blocker. If some conflict is pushed to
> master the project is dead until it is resolved (how often have we seen
> this?)
This is completely detached from github reality.
In this model, all contributors work actually on the same branch. In
github, every contributor will fork off their own dev branch.
In this model, people start with a fork off the dev branch and push to dev
branch. In github, a contributor will fork off the master branch and will
PR against master branch. This is default behavior and my gut feeling no
amount of forewarning is going to change that w.r.t. contributors. And if
one starts off his/her work with the branch with intent to commit to
another, then conflict is guaranteed every time he or she changes the file
that has been changed on the branch to be merged to.
For example:
Master is at A
Dev branch is at A - B -C ... F.
if I start working at master (A) then i wil generate conflicts if i have
changed same files (lines) as in B, C, .. or F.
If I start working at dev (F) then i will not have a chance to generate
conflicts with B,C,..F but only with commits that happened after i had
started.
Also, if I start working at master (A) then github flow will suggest me to
merge into master during PR. I guarantee 100% of first time PRs will trip
on that in github. even if you put "start your work off dev not master" 20
times into project readme.
And then you will face the dilemma whether to ask people to resolve merge
issues w.r.t. master and resubmit, 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 errors.
-d
Re: Proposal for changing Mahout's Git branching rules
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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/ <http://nvie.com/posts/a-successful-git-branching-model/>
I still don’t see how this complicates resolving conflicts. It just removes the resolution from being a blocker. If some conflict is pushed to master the project is dead until it is resolved (how often have we seen this?) With git flow, not so, because this never happens (or very rarely) You could see the same problem occur in develop but wouldn't best practice be to resolve known conflicts in a separate branch where stakeholders collaborate, then once resolved merge with develop and purge the ephemeral branch? I’ve seen this work well though the work is not and never will be easy, at least it doesn’t get in other people’s way.
On Jun 21, 2017, at 2:26 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
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 <dl...@gmail.com> wrote:
>
>
> On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com> 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 if you don't have
> proper target, you can't ask the contributor.
>
> and some projects like PredictionIO make develop the default branch on
>> github so it's the one contributors get by default.
>>
> That would fix it but i am not sure if we have access to HEAD on github
> mirror. Might involve INFRA to do it And in that case it would amount
> little more but renaming. It would seem it is much easier to create a
> branch, "stable master" or something, and consider master to be ongoing PR
> base.
>
> -1 on former, -0 on the latter. Judging from the point of both contributor
> and committer (of which I am both).it will not make my life easy on either
> end.
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <pa...@occamsmachete.com> wrote:
Which translates into exactly what you suggest if we are maintaining release branches.
On Jun 22, 2017, at 10:45 AM, Pat Ferrel <pa...@occamsmachete.com> 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 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 hotfixes applied even if the merge does not warrant a binary release.
The master branch hygiene is maintained by checking WIP into develop or a feature branch, hotfixes and releases go into master. There is also a mechanism to maintain release branches if the project warrants, which may be true of Mahout.
On Jun 21, 2017, at 3:25 PM, Trevor Grant <tr...@gmail.com> wrote:
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 <dl...@gmail.com> wrote:
> 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 <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com>
> 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 if you don't have
>> proper target, you can't ask the contributor.
>>
>> and some projects like PredictionIO make develop the default branch on
>>> github so it's the one contributors get by default.
>>>
>> That would fix it but i am not sure if we have access to HEAD on github
>> mirror. Might involve INFRA to do it And in that case it would amount
>> little more but renaming. It would seem it is much easier to create a
>> branch, "stable master" or something, and consider master to be ongoing
> PR
>> base.
>>
>> -1 on former, -0 on the latter. Judging from the point of both
> contributor
>> and committer (of which I am both).it will not make my life easy on
> either
>> end.
>>
>>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Pat Ferrel <pa...@occamsmachete.com>.
Which translates into exactly what you suggest if we are maintaining release branches.
On Jun 22, 2017, at 10:45 AM, Pat Ferrel <pa...@occamsmachete.com> 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 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 hotfixes applied even if the merge does not warrant a binary release.
The master branch hygiene is maintained by checking WIP into develop or a feature branch, hotfixes and releases go into master. There is also a mechanism to maintain release branches if the project warrants, which may be true of Mahout.
On Jun 21, 2017, at 3:25 PM, Trevor Grant <tr...@gmail.com> wrote:
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 <dl...@gmail.com> wrote:
> 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 <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com>
> 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 if you don't have
>> proper target, you can't ask the contributor.
>>
>> and some projects like PredictionIO make develop the default branch on
>>> github so it's the one contributors get by default.
>>>
>> That would fix it but i am not sure if we have access to HEAD on github
>> mirror. Might involve INFRA to do it And in that case it would amount
>> little more but renaming. It would seem it is much easier to create a
>> branch, "stable master" or something, and consider master to be ongoing
> PR
>> base.
>>
>> -1 on former, -0 on the latter. Judging from the point of both
> contributor
>> and committer (of which I am both).it will not make my life easy on
> either
>> end.
>>
>>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 hotfixes applied even if the merge does not warrant a binary release.
The master branch hygiene is maintained by checking WIP into develop or a feature branch, hotfixes and releases go into master. There is also a mechanism to maintain release branches if the project warrants, which may be true of Mahout.
On Jun 21, 2017, at 3:25 PM, Trevor Grant <tr...@gmail.com> wrote:
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 <dl...@gmail.com> wrote:
> 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 <dl...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com>
> 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 if you don't have
>> proper target, you can't ask the contributor.
>>
>> and some projects like PredictionIO make develop the default branch on
>>> github so it's the one contributors get by default.
>>>
>> That would fix it but i am not sure if we have access to HEAD on github
>> mirror. Might involve INFRA to do it And in that case it would amount
>> little more but renaming. It would seem it is much easier to create a
>> branch, "stable master" or something, and consider master to be ongoing
> PR
>> base.
>>
>> -1 on former, -0 on the latter. Judging from the point of both
> contributor
>> and committer (of which I am both).it will not make my life easy on
> either
>> end.
>>
>>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Trevor Grant <tr...@gmail.com>.
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 <dl...@gmail.com> wrote:
> 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 <dl...@gmail.com>
> wrote:
>
> >
> >
> > On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com>
> 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 if you don't have
> > proper target, you can't ask the contributor.
> >
> > and some projects like PredictionIO make develop the default branch on
> >> github so it's the one contributors get by default.
> >>
> > That would fix it but i am not sure if we have access to HEAD on github
> > mirror. Might involve INFRA to do it And in that case it would amount
> > little more but renaming. It would seem it is much easier to create a
> > branch, "stable master" or something, and consider master to be ongoing
> PR
> > base.
> >
> > -1 on former, -0 on the latter. Judging from the point of both
> contributor
> > and committer (of which I am both).it will not make my life easy on
> either
> > end.
> >
> >
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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 <dl...@gmail.com> wrote:
>
>
> On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com> 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 if you don't have
> proper target, you can't ask the contributor.
>
> and some projects like PredictionIO make develop the default branch on
>> github so it's the one contributors get by default.
>>
> That would fix it but i am not sure if we have access to HEAD on github
> mirror. Might involve INFRA to do it And in that case it would amount
> little more but renaming. It would seem it is much easier to create a
> branch, "stable master" or something, and consider master to be ongoing PR
> base.
>
> -1 on former, -0 on the latter. Judging from the point of both contributor
> and committer (of which I am both).it will not make my life easy on either
> end.
>
>
Re: Proposal for changing Mahout's Git branching rules
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com> 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 if you don't have
proper target, you can't ask the contributor.
and some projects like PredictionIO make develop the default branch on
> github so it's the one contributors get by default.
>
That would fix it but i am not sure if we have access to HEAD on github
mirror. Might involve INFRA to do it And in that case it would amount
little more but renaming. It would seem it is much easier to create a
branch, "stable master" or something, and consider master to be ongoing PR
base.
-1 on former, -0 on the latter. Judging from the point of both contributor
and committer (of which I am both).it will not make my life easy on either
end.
Re: Proposal for changing Mahout's Git branching rules
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 left stable and ignored until a release or bug fix is needed before the next release.
We already have various branches and now that we can clean them up without involving Infra, the rest of your question is resolved by the originator of the change just like today.
I see the key benefits as:
1) as I’ve already over stated, master is stable
2) we have a documented process that is IMO a “best practice”. Even if we stick with the process of today we need to document it as release artifacts and branches proliferate.
On Jun 21, 2017, at 2:06 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
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 <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
>> 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 like a lot of branches but in practice it’s trivial to merge and
>> purge. Everything stays clean and rapid fire last minute fixes are
> isolated
>> to the release branch before going into master.
>>
>> The original reason I brought this up is that our Git tools now allow
>> committers to delete old cruft laden branches that are created and
>> ephemeral with this method.
>>
>>
>> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>>
>> 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* without git flow. With git
> flow
>> you can peel off a bug fix and merge with master and users can pull it
>> expecting that everything else is stable and like the last build. This
> has
>> bit me with Mahout in the past as I’m sure it has for everyone. This
>> doesn’t fix that but it does limit the pain to committers.
>>
>> If we aren’t going to use it, fine but let’s not agree to it then do
>> something else. If it’s a matter of timing ok, I understood from Andrew’s
>> mail below there was no timing issue but I expect there will be Jenkins
> or
>> Travis issues to iron out.
>>
>> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
>> http://nvie.com/posts/a-successful-git-branching-model/> I have never
>> heard of someone who has tried it that didn’t like it but it takes a leap
>> of faith unless you have git in your bones.
>>
>>
>> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
>> wrote:
>>
>> 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 <pa...@occamsmachete.com>
>> 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 <
>> andrew.musselman@gmail.com>
>>> 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 <pa...@occamsmachete.com>
>>> 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.musselman@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 <pa...@occamsmachete.com>
>>>> 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
Posted by Andrew Palumbo <ap...@outlook.com>.
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.1.x for scala 2.11 and scala 2.10. we'd hoped it would be straightforward and it was something almost automatable.
The git-flow change idea was floated by you, i believe you around the same time (correct me if I'm wrong.. this was all happening while I was sick). I agree that it should be a team decision, but it also might take some time to transition.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Dmitriy Lyubimov <dl...@gmail.com>
Date: 06/21/2017 2:06 PM (GMT-08:00)
To: user@mahout.apache.org
Cc: Mahout Dev List <de...@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 and merging into
different targets?
On Tue, Jun 20, 2017 at 10:09 AM, Pat Ferrel <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> > 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 like a lot of branches but in practice it’s trivial to merge and
> > purge. Everything stays clean and rapid fire last minute fixes are
> isolated
> > to the release branch before going into master.
> >
> > The original reason I brought this up is that our Git tools now allow
> > committers to delete old cruft laden branches that are created and
> > ephemeral with this method.
> >
> >
> > On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> >
> > 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* without git flow. With git
> flow
> > you can peel off a bug fix and merge with master and users can pull it
> > expecting that everything else is stable and like the last build. This
> has
> > bit me with Mahout in the past as I’m sure it has for everyone. This
> > doesn’t fix that but it does limit the pain to committers.
> >
> > If we aren’t going to use it, fine but let’s not agree to it then do
> > something else. If it’s a matter of timing ok, I understood from Andrew’s
> > mail below there was no timing issue but I expect there will be Jenkins
> or
> > Travis issues to iron out.
> >
> > For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> > http://nvie.com/posts/a-successful-git-branching-model/> I have never
> > heard of someone who has tried it that didn’t like it but it takes a leap
> > of faith unless you have git in your bones.
> >
> >
> > On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
> > wrote:
> >
> > 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 <pa...@occamsmachete.com>
> > 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 <
> > andrew.musselman@gmail.com>
> >> 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 <pa...@occamsmachete.com>
> >> 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.musselman@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 <pa...@occamsmachete.com>
> >>> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 left stable and ignored until a release or bug fix is needed before the next release.
We already have various branches and now that we can clean them up without involving Infra, the rest of your question is resolved by the originator of the change just like today.
I see the key benefits as:
1) as I’ve already over stated, master is stable
2) we have a documented process that is IMO a “best practice”. Even if we stick with the process of today we need to document it as release artifacts and branches proliferate.
On Jun 21, 2017, at 2:06 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
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 <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
>> 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 like a lot of branches but in practice it’s trivial to merge and
>> purge. Everything stays clean and rapid fire last minute fixes are
> isolated
>> to the release branch before going into master.
>>
>> The original reason I brought this up is that our Git tools now allow
>> committers to delete old cruft laden branches that are created and
>> ephemeral with this method.
>>
>>
>> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>>
>> 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* without git flow. With git
> flow
>> you can peel off a bug fix and merge with master and users can pull it
>> expecting that everything else is stable and like the last build. This
> has
>> bit me with Mahout in the past as I’m sure it has for everyone. This
>> doesn’t fix that but it does limit the pain to committers.
>>
>> If we aren’t going to use it, fine but let’s not agree to it then do
>> something else. If it’s a matter of timing ok, I understood from Andrew’s
>> mail below there was no timing issue but I expect there will be Jenkins
> or
>> Travis issues to iron out.
>>
>> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
>> http://nvie.com/posts/a-successful-git-branching-model/> I have never
>> heard of someone who has tried it that didn’t like it but it takes a leap
>> of faith unless you have git in your bones.
>>
>>
>> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
>> wrote:
>>
>> 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 <pa...@occamsmachete.com>
>> 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 <
>> andrew.musselman@gmail.com>
>>> 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 <pa...@occamsmachete.com>
>>> 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.musselman@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 <pa...@occamsmachete.com>
>>>> 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
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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 <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> > 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 like a lot of branches but in practice it’s trivial to merge and
> > purge. Everything stays clean and rapid fire last minute fixes are
> isolated
> > to the release branch before going into master.
> >
> > The original reason I brought this up is that our Git tools now allow
> > committers to delete old cruft laden branches that are created and
> > ephemeral with this method.
> >
> >
> > On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> >
> > 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* without git flow. With git
> flow
> > you can peel off a bug fix and merge with master and users can pull it
> > expecting that everything else is stable and like the last build. This
> has
> > bit me with Mahout in the past as I’m sure it has for everyone. This
> > doesn’t fix that but it does limit the pain to committers.
> >
> > If we aren’t going to use it, fine but let’s not agree to it then do
> > something else. If it’s a matter of timing ok, I understood from Andrew’s
> > mail below there was no timing issue but I expect there will be Jenkins
> or
> > Travis issues to iron out.
> >
> > For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> > http://nvie.com/posts/a-successful-git-branching-model/> I have never
> > heard of someone who has tried it that didn’t like it but it takes a leap
> > of faith unless you have git in your bones.
> >
> >
> > On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
> > wrote:
> >
> > 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 <pa...@occamsmachete.com>
> > 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 <
> > andrew.musselman@gmail.com>
> >> 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 <pa...@occamsmachete.com>
> >> 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.musselman@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 <pa...@occamsmachete.com>
> >>> 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
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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 <pa...@actionml.com> wrote:
> 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 examples
> too so I don’t see the benefit of using an ad hoc method in terms of CI.
> We’ve used this method for years with Apache PredictionIO with minimal CI
> issues.
>
> No the process below is not equivalent, treating master as develop removes
> the primary (in my mind) benefit. In git flow the master is always stable
> and the reflection of the last primary/core/default release with only
> critical inter-release fixes. If someone wants to work with stable
> up-to-date source, where do they go with the current process? I would claim
> that there actually may be no place to find such a thing except by tracking
> down some working commit number. It would depend on what stage the project
> is in, in git flow there is never a question—master is always stable. Git
> flow also accounts for all the process exceptions and complexities you
> mention below but in a standardized way that is documented so anyone can
> read the rules and follow them. We/Mahout doesn’t even have to write them,
> they can just be referenced.
>
> But we are re-arguing something I thought was already voted on and that is
> another issue. If we need to re-debate this let’s make it stick one way or
> the other.
>
> I really appreciate you being release master and the thought and work
> you’ve put into this and if we decide to stick with it, fine. But it should
> be a project decision that release masters follow, not up to each release
> master. We are now embarking on a much more complex release than before
> with multiple combinations of dependencies for binaries and so multiple
> artifacts. We need to make the effort tame the complexity somehow or it
> will just multiply.
>
> 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.
>
>
> On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com>
> wrote:
>
> 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 current method is, when we cut a release- we make a new branch of that
> release. Master is treated like dev. If you want the latest stable, you
> would check out branch-0.13.0 . This is the way most major projects
> (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
> worked. To your point, there being a lack of a recent stable- that's fair,
> but partly that's because no one created branches with the release for
> 0.10.? - 0.12.2.
>
> For all intents and purposes, we are (now once again) following what you
> propose, the only difference is we are treating master as dev, and
> "branch-0.13.0" as master (e.g. last stable). Larger features go on their
> own branch until they are ready to merge- e.g. ATM there is just one
> feature branch CUDA. That was the big take away from this discussion last
> time- there needed to be feature branches, as opposed to everyone running
> around either working off WIP PRs or half baked merges, etc. To that end-
> "website" was a feature branch, and iirc there has been one other feature
> branch that has merged in the last couple of months but I forget what it
> was at the moment.
>
>
>
>
>
>
> Trevor Grant
> Data Scientist
> https://github.com/rawkintrevo
> http://stackexchange.com/users/3002022/rawkintrevo
> http://trevorgrant.org
>
> *"Fortunate is he, who is able to know the causes of things." -Virgil*
>
>
> On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> > 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 like a lot of branches but in practice it’s trivial to merge and
> > purge. Everything stays clean and rapid fire last minute fixes are
> isolated
> > to the release branch before going into master.
> >
> > The original reason I brought this up is that our Git tools now allow
> > committers to delete old cruft laden branches that are created and
> > ephemeral with this method.
> >
> >
> > On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> >
> > 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* without git flow. With git
> flow
> > you can peel off a bug fix and merge with master and users can pull it
> > expecting that everything else is stable and like the last build. This
> has
> > bit me with Mahout in the past as I’m sure it has for everyone. This
> > doesn’t fix that but it does limit the pain to committers.
> >
> > If we aren’t going to use it, fine but let’s not agree to it then do
> > something else. If it’s a matter of timing ok, I understood from Andrew’s
> > mail below there was no timing issue but I expect there will be Jenkins
> or
> > Travis issues to iron out.
> >
> > For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> > http://nvie.com/posts/a-successful-git-branching-model/> I have never
> > heard of someone who has tried it that didn’t like it but it takes a leap
> > of faith unless you have git in your bones.
> >
> >
> > On Apr 22, 2017, at 10:42 AM, Andrew Musselman <
> andrew.musselman@gmail.com>
> > wrote:
> >
> > 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 <pa...@occamsmachete.com>
> > 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 <
> > andrew.musselman@gmail.com>
> >> 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 <pa...@occamsmachete.com>
> >> 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.musselman@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 <pa...@occamsmachete.com>
> >>> 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
Posted by Pat Ferrel <pa...@actionml.com>.
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 examples too so I don’t see the benefit of using an ad hoc method in terms of CI. We’ve used this method for years with Apache PredictionIO with minimal CI issues.
No the process below is not equivalent, treating master as develop removes the primary (in my mind) benefit. In git flow the master is always stable and the reflection of the last primary/core/default release with only critical inter-release fixes. If someone wants to work with stable up-to-date source, where do they go with the current process? I would claim that there actually may be no place to find such a thing except by tracking down some working commit number. It would depend on what stage the project is in, in git flow there is never a question—master is always stable. Git flow also accounts for all the process exceptions and complexities you mention below but in a standardized way that is documented so anyone can read the rules and follow them. We/Mahout doesn’t even have to write them, they can just be referenced.
But we are re-arguing something I thought was already voted on and that is another issue. If we need to re-debate this let’s make it stick one way or the other.
I really appreciate you being release master and the thought and work you’ve put into this and if we decide to stick with it, fine. But it should be a project decision that release masters follow, not up to each release master. We are now embarking on a much more complex release than before with multiple combinations of dependencies for binaries and so multiple artifacts. We need to make the effort tame the complexity somehow or it will just multiply.
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.
On Jun 19, 2017, at 9:04 PM, Trevor Grant <tr...@gmail.com> wrote:
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 current method is, when we cut a release- we make a new branch of that
release. Master is treated like dev. If you want the latest stable, you
would check out branch-0.13.0 . This is the way most major projects
(citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
worked. To your point, there being a lack of a recent stable- that's fair,
but partly that's because no one created branches with the release for
0.10.? - 0.12.2.
For all intents and purposes, we are (now once again) following what you
propose, the only difference is we are treating master as dev, and
"branch-0.13.0" as master (e.g. last stable). Larger features go on their
own branch until they are ready to merge- e.g. ATM there is just one
feature branch CUDA. That was the big take away from this discussion last
time- there needed to be feature branches, as opposed to everyone running
around either working off WIP PRs or half baked merges, etc. To that end-
"website" was a feature branch, and iirc there has been one other feature
branch that has merged in the last couple of months but I forget what it
was at the moment.
Trevor Grant
Data Scientist
https://github.com/rawkintrevo
http://stackexchange.com/users/3002022/rawkintrevo
http://trevorgrant.org
*"Fortunate is he, who is able to know the causes of things." -Virgil*
On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> 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 like a lot of branches but in practice it’s trivial to merge and
> purge. Everything stays clean and rapid fire last minute fixes are isolated
> to the release branch before going into master.
>
> The original reason I brought this up is that our Git tools now allow
> committers to delete old cruft laden branches that are created and
> ephemeral with this method.
>
>
> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> 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* without git flow. With git flow
> you can peel off a bug fix and merge with master and users can pull it
> expecting that everything else is stable and like the last build. This has
> bit me with Mahout in the past as I’m sure it has for everyone. This
> doesn’t fix that but it does limit the pain to committers.
>
> If we aren’t going to use it, fine but let’s not agree to it then do
> something else. If it’s a matter of timing ok, I understood from Andrew’s
> mail below there was no timing issue but I expect there will be Jenkins or
> Travis issues to iron out.
>
> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> http://nvie.com/posts/a-successful-git-branching-model/> I have never
> heard of someone who has tried it that didn’t like it but it takes a leap
> of faith unless you have git in your bones.
>
>
> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com>
> wrote:
>
> 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 <pa...@occamsmachete.com>
> 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 <
> andrew.musselman@gmail.com>
>> 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 <pa...@occamsmachete.com>
>> 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.musselman@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 <pa...@occamsmachete.com>
>>> 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
Posted by Trevor Grant <tr...@gmail.com>.
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 current method is, when we cut a release- we make a new branch of that
release. Master is treated like dev. If you want the latest stable, you
would check out branch-0.13.0 . This is the way most major projects
(citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
worked. To your point, there being a lack of a recent stable- that's fair,
but partly that's because no one created branches with the release for
0.10.? - 0.12.2.
For all intents and purposes, we are (now once again) following what you
propose, the only difference is we are treating master as dev, and
"branch-0.13.0" as master (e.g. last stable). Larger features go on their
own branch until they are ready to merge- e.g. ATM there is just one
feature branch CUDA. That was the big take away from this discussion last
time- there needed to be feature branches, as opposed to everyone running
around either working off WIP PRs or half baked merges, etc. To that end-
"website" was a feature branch, and iirc there has been one other feature
branch that has merged in the last couple of months but I forget what it
was at the moment.
Trevor Grant
Data Scientist
https://github.com/rawkintrevo
http://stackexchange.com/users/3002022/rawkintrevo
http://trevorgrant.org
*"Fortunate is he, who is able to know the causes of things." -Virgil*
On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> 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 like a lot of branches but in practice it’s trivial to merge and
> purge. Everything stays clean and rapid fire last minute fixes are isolated
> to the release branch before going into master.
>
> The original reason I brought this up is that our Git tools now allow
> committers to delete old cruft laden branches that are created and
> ephemeral with this method.
>
>
> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> 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* without git flow. With git flow
> you can peel off a bug fix and merge with master and users can pull it
> expecting that everything else is stable and like the last build. This has
> bit me with Mahout in the past as I’m sure it has for everyone. This
> doesn’t fix that but it does limit the pain to committers.
>
> If we aren’t going to use it, fine but let’s not agree to it then do
> something else. If it’s a matter of timing ok, I understood from Andrew’s
> mail below there was no timing issue but I expect there will be Jenkins or
> Travis issues to iron out.
>
> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> http://nvie.com/posts/a-successful-git-branching-model/> I have never
> heard of someone who has tried it that didn’t like it but it takes a leap
> of faith unless you have git in your bones.
>
>
> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com>
> wrote:
>
> 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 <pa...@occamsmachete.com>
> 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 <
> andrew.musselman@gmail.com>
> > 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 <pa...@occamsmachete.com>
> > 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.musselman@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 <pa...@occamsmachete.com>
> >> 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
Posted by Trevor Grant <tr...@gmail.com>.
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 current method is, when we cut a release- we make a new branch of that
release. Master is treated like dev. If you want the latest stable, you
would check out branch-0.13.0 . This is the way most major projects
(citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x
worked. To your point, there being a lack of a recent stable- that's fair,
but partly that's because no one created branches with the release for
0.10.? - 0.12.2.
For all intents and purposes, we are (now once again) following what you
propose, the only difference is we are treating master as dev, and
"branch-0.13.0" as master (e.g. last stable). Larger features go on their
own branch until they are ready to merge- e.g. ATM there is just one
feature branch CUDA. That was the big take away from this discussion last
time- there needed to be feature branches, as opposed to everyone running
around either working off WIP PRs or half baked merges, etc. To that end-
"website" was a feature branch, and iirc there has been one other feature
branch that has merged in the last couple of months but I forget what it
was at the moment.
Trevor Grant
Data Scientist
https://github.com/rawkintrevo
http://stackexchange.com/users/3002022/rawkintrevo
http://trevorgrant.org
*"Fortunate is he, who is able to know the causes of things." -Virgil*
On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> 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 like a lot of branches but in practice it’s trivial to merge and
> purge. Everything stays clean and rapid fire last minute fixes are isolated
> to the release branch before going into master.
>
> The original reason I brought this up is that our Git tools now allow
> committers to delete old cruft laden branches that are created and
> ephemeral with this method.
>
>
> On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> 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* without git flow. With git flow
> you can peel off a bug fix and merge with master and users can pull it
> expecting that everything else is stable and like the last build. This has
> bit me with Mahout in the past as I’m sure it has for everyone. This
> doesn’t fix that but it does limit the pain to committers.
>
> If we aren’t going to use it, fine but let’s not agree to it then do
> something else. If it’s a matter of timing ok, I understood from Andrew’s
> mail below there was no timing issue but I expect there will be Jenkins or
> Travis issues to iron out.
>
> For reference: http://nvie.com/posts/a-successful-git-branching-model/ <
> http://nvie.com/posts/a-successful-git-branching-model/> I have never
> heard of someone who has tried it that didn’t like it but it takes a leap
> of faith unless you have git in your bones.
>
>
> On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com>
> wrote:
>
> 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 <pa...@occamsmachete.com>
> 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 <
> andrew.musselman@gmail.com>
> > 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 <pa...@occamsmachete.com>
> > 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.musselman@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 <pa...@occamsmachete.com>
> >> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 like a lot of branches but in practice it’s trivial to merge and purge. Everything stays clean and rapid fire last minute fixes are isolated to the release branch before going into master.
The original reason I brought this up is that our Git tools now allow committers to delete old cruft laden branches that are created and ephemeral with this method.
On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
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* without git flow. With git flow you can peel off a bug fix and merge with master and users can pull it expecting that everything else is stable and like the last build. This has bit me with Mahout in the past as I’m sure it has for everyone. This doesn’t fix that but it does limit the pain to committers.
If we aren’t going to use it, fine but let’s not agree to it then do something else. If it’s a matter of timing ok, I understood from Andrew’s mail below there was no timing issue but I expect there will be Jenkins or Travis issues to iron out.
For reference: http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/> I have never heard of someone who has tried it that didn’t like it but it takes a leap of faith unless you have git in your bones.
On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com> wrote:
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 <pa...@occamsmachete.com> 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 <an...@gmail.com>
> 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 <pa...@occamsmachete.com>
> 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.musselman@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 <pa...@occamsmachete.com>
>> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 like a lot of branches but in practice it’s trivial to merge and purge. Everything stays clean and rapid fire last minute fixes are isolated to the release branch before going into master.
The original reason I brought this up is that our Git tools now allow committers to delete old cruft laden branches that are created and ephemeral with this method.
On Jun 19, 2017, at 5:52 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
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* without git flow. With git flow you can peel off a bug fix and merge with master and users can pull it expecting that everything else is stable and like the last build. This has bit me with Mahout in the past as I’m sure it has for everyone. This doesn’t fix that but it does limit the pain to committers.
If we aren’t going to use it, fine but let’s not agree to it then do something else. If it’s a matter of timing ok, I understood from Andrew’s mail below there was no timing issue but I expect there will be Jenkins or Travis issues to iron out.
For reference: http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/> I have never heard of someone who has tried it that didn’t like it but it takes a leap of faith unless you have git in your bones.
On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com> wrote:
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 <pa...@occamsmachete.com> 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 <an...@gmail.com>
> 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 <pa...@occamsmachete.com>
> 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.musselman@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 <pa...@occamsmachete.com>
>> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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* without git flow. With git flow you can peel off a bug fix and merge with master and users can pull it expecting that everything else is stable and like the last build. This has bit me with Mahout in the past as I’m sure it has for everyone. This doesn’t fix that but it does limit the pain to committers.
If we aren’t going to use it, fine but let’s not agree to it then do something else. If it’s a matter of timing ok, I understood from Andrew’s mail below there was no timing issue but I expect there will be Jenkins or Travis issues to iron out.
For reference: http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/> I have never heard of someone who has tried it that didn’t like it but it takes a leap of faith unless you have git in your bones.
On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com> wrote:
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 <pa...@occamsmachete.com> 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 <an...@gmail.com>
> 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 <pa...@occamsmachete.com>
> 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.musselman@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 <pa...@occamsmachete.com>
>> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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* without git flow. With git flow you can peel off a bug fix and merge with master and users can pull it expecting that everything else is stable and like the last build. This has bit me with Mahout in the past as I’m sure it has for everyone. This doesn’t fix that but it does limit the pain to committers.
If we aren’t going to use it, fine but let’s not agree to it then do something else. If it’s a matter of timing ok, I understood from Andrew’s mail below there was no timing issue but I expect there will be Jenkins or Travis issues to iron out.
For reference: http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/> I have never heard of someone who has tried it that didn’t like it but it takes a leap of faith unless you have git in your bones.
On Apr 22, 2017, at 10:42 AM, Andrew Musselman <an...@gmail.com> wrote:
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 <pa...@occamsmachete.com> 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 <an...@gmail.com>
> 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 <pa...@occamsmachete.com>
> 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.musselman@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 <pa...@occamsmachete.com>
>> 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
Posted by Andrew Musselman <an...@gmail.com>.
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 <pa...@occamsmachete.com> 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 <an...@gmail.com>
> 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 <pa...@occamsmachete.com>
> 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.musselman@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 <pa...@occamsmachete.com>
> > 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
Posted by Andrew Musselman <an...@gmail.com>.
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 <pa...@occamsmachete.com> 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 <an...@gmail.com>
> 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 <pa...@occamsmachete.com>
> 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.musselman@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 <pa...@occamsmachete.com>
> > 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <an...@gmail.com> 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 <pa...@occamsmachete.com> 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 <an...@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 <pa...@occamsmachete.com>
> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <an...@gmail.com> 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 <pa...@occamsmachete.com> 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 <an...@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 <pa...@occamsmachete.com>
> 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
Posted by Andrew Musselman <an...@gmail.com>.
Cool, I'll make a new dev branch now.
Dev, develop, any preference?
On Sat, Apr 22, 2017 at 10:30 AM, Pat Ferrel <pa...@occamsmachete.com> 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 <an...@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 <pa...@occamsmachete.com>
> 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
Posted by Andrew Musselman <an...@gmail.com>.
Cool, I'll make a new dev branch now.
Dev, develop, any preference?
On Sat, Apr 22, 2017 at 10:30 AM, Pat Ferrel <pa...@occamsmachete.com> 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 <an...@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 <pa...@occamsmachete.com>
> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <an...@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 <pa...@occamsmachete.com> 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
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <an...@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 <pa...@occamsmachete.com> 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
Posted by Andrew Musselman <an...@gmail.com>.
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 <pa...@occamsmachete.com> 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
Posted by Andrew Musselman <an...@gmail.com>.
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 <pa...@occamsmachete.com> 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?