Clarify (and streamline?) workflow for coordinating changes with mapbox-gl-js

[anandthakker]

When working on a change in this repo that depends on a change to mapbox-gl-js (shaders, integration tests, style spec) -- e.g., #7944 -- I'm finding the flow for management to be a bit clunky. Here's what I am doing now:

1. Open a work-in-progress PR/branch in mapbox-gl-js with the changes needed there. (Example: [not ready] Enable DDS for text-{field,transform} in gl-native mapbox-gl-js#4212 un-skips the integration tests relevant to enabling DDS for text-field, text-transform.)
2. Open a PR with the proposed changes here, including a commit that updates the mapbox-gl-js submodule to the wip branch from step 1) ☝️.
3. While waiting for or responding to reviews, mapbox-gl-native/master and mapbox-gl-js/master may continue to move along, including the possibility that -native/master needs to track updates in gl-js/master. So, from time to time, rebase the branch in step 1) and then the PR branch here.
4. Once we're 🍏, merge the PR here to mapbox-gl-native/master. Then merge the dependent PR to mapbox-gl-js/master, but don't delete the branch. Now, put in a new change to -native, updating the submodule to mapbox-gl-js/master. Once it's merged, delete the lingering gl-js branch.

Note that the situation in step 3 is the reason that we have to keep the gl-js branch separate while work is in progress: merging it into gl-js/master ahead of time would break things for anyone else developing on -native who needed to pull in some other update to gl-js.

As best I can tell, this three-PRs-for-the-price-of-one thing is necessary, but I'm wondering if maybe I've missed something. If it is necessary, that's fine -- it's not like it's actually much extra work... but I do think it's weird/finicky enough to be error-prone, so we should document the process.

[jfirebaugh]

I do step 4 differently:

4. Once we're 🍏, merge the PR to mapbox-gl-js. If it can be fast-forward merged, then do that (via the command line) -- this saves having to reupdate the submodule SHA in mapbox-gl-native. Otherwise, rebase and merge. Then update the submodule SHA in mapbox-gl-native if necessary, and merge the mapbox-gl-native PR.

Still finicky, but AFAIK this is the best we can do unless we go full monorepo. It used to be worse!

[anandthakker]

Ah yeah, that's definitely a bit better @jfirebaugh. And like I said, it's not actually that bad, but tricky enough that I think having a step-by-step to follow would be helpful.

[boundsj]

Thanks for writing this down @anandthakker! I checked for something like this in our wikis to help me with the regression test I need to add for #8078. Having these steps in a place to reference (besides this issue) would be helpful, I think.

[jfirebaugh]

https://github.com/mapbox/mapbox-gl-native/wiki/JS-Native-workflow