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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote: