+1
Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Andrew Musselman <andrew.mussel...@gmail.com> Date: 08/02/2017 3:12 PM (GMT-08:00) To: dev@mahout.apache.org Subject: Re: Proposal for changing Mahout's Git branching rules I'm in favor of keeping it simple too, and the idea of scaring away new folks tipped the scale for me; thanks for the good discussion. On Tue, Jul 25, 2017 at 11:53 AM, Andrew Palumbo <ap....@outlook.com> wrote: > > > > > Sent from my Verizon Wireless 4G LTE smartphone > > > -------- Original message -------- > From: Trevor Grant <trevor.d.gr...@gmail.com> > Date: 07/25/2017 07:38 (GMT-08:00) > To: Mahout Dev List <dev@mahout.apache.org> > Subject: Re: Proposal for changing Mahout's Git branching rules > > > +100 > > > 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 <dlie...@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 <dlie...@gmail.com> > > wrote: > > > > > > > > > > > On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel <p...@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 > > >> >> > > >> > > > >> > > > >> > > >> > > > > > >
