mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trevor Grant <trevor.d.gr...@gmail.com>
Subject Re: Proposal for changing Mahout's Git branching rules
Date Tue, 20 Jun 2017 04:04:10 GMT
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 <pat@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 <pat@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 <pat@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 <pat@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 <pat@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?
> >>
> >>
> >
> >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message