ongoing upstream-merge strategy from node

[Fishrock123]

This is something that will be a whole lot more prevalent with a modern fork, there is still going to be a large amount of ongoing work into nodejs/node that would be very useful to keep in sync with.

This wasn't really a problem at the time of io.js, so I'm not sure there is much to learn from there.

However, I think we may be able to make do by keeping a branch in sync with nodejs/node master, and a staging branch for our own commits - very similar to how node does its releases - and then cut releases by rebasing the two into a release branch.
Not the most pleasant perhaps, but It should be workable, I think.

[addaleax]

I don’t think repeated rebases are really sustainable; once you get into merge conflicts, I can’t see how that goes well…? (Or at the no of conflicts scales about linearly with the # of commits in each branch)

In my head, the options would be either cherry-picking commits from upstream as much as it’s possible, or actually doing git merges (which may not be pretty but work well for this kind of thing, I guess).

[sandfox]

From the point of view of having tried something similar of private codebase where we had a much greater ability to push -f to the downstream, we quickly gave up on trying to rebase onto the upstream and it's changes. The amount of work seemed to scale exponentially over time and the number of commits we differed by and very quickly became hard to understand. We then switched over to a mix of cherry picking, copy+pasta, and generating patches arcanely.
We did keep a branch that was synced with with the upstream , but I can't remember why, or if it really helped much other than for diff views in github.

[Qard]

Might it be reasonable to pull request any changes unique to ayo back to Node.js to try and keep both projects as much in-sync as possible?

[addaleax]

@Qard That would be helpful wrt avoiding merge conflicts, yes.

Honestly, one thing that has become annoying about Node core (imo) is the tendency to review larger PRs to death, until nobody has interest in continuing the review process anymore, the PR stalls and gets closed after a few weeks or months.

I would hope that Ayo can avoid that, but if we want to reintegrate our changes here into Node, then that may or may not get pretty exhausting.

[Qard]

Anyone with experience with the release PR tooling and github integrations have any thoughts on how difficult it'd be to make some automation that automagically opens a PR on nodejs/node for each PR merged to ayojs/ayo? Would that be better than big upstream-syncing PRs?

[sandfox]

@Qard would this be vaguely good enough? http://backstroke.us/ https://github.com/1egoman/backstroke#readme we're using it keep a downstream fork of create-react-app synced at $dayjob. So far it's been ok!

[Fishrock123]

From #22, the current plan is to rebase commits from upstream Node ontop of our commits.

[Fishrock123]

I'd like to give it a few more and then document it.