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 <dlie...@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 <dlie...@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 <dlie...@gmail.com> > wrote: > >> >> >> On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <p...@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 >> > >
