Proposal for changing Mahout's Git branching rules

[Andrew Musselman]

I'm in favor of keeping it simple too, and the idea of scaring away new
folks tipped the scale for me; thanks for the good discussion.

Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
Date: 07/25/2017 07:38 (GMT-08:00)
Subject: Re: Proposal for changing Mahout's Git branching rules
+100
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

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.

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.

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