Making mozilla-central the canonical upstream for webrender

[Kartikaya Gupta]

As I mentioned in the WR meeting today, I'd like to make
mozilla-central the canonical home of webrender effective today.
Specifically, since PR #3493 is already inflight, I'd like that to be
the last PR merged from the Github side. All future PRs would go
through Phabricator and mozilla-central, and then get synced to
GitHub.

I've updated the documentation at [1] to describe how to do try pushes
for the webrender standalone CI jobs (please read that section all the
way to the end, the last section there will be useful to many of you).

For submitting to Phabricator, please use the standard mozilla-central
workflow and setup, documented at [2].

I have a script that will take commits to WR code from mozilla-central
and make a PR against the github repo to do the sync in that
direction. To avoid merge conflicts, these should be the only PRs
getting merged on the Github side. Hopefully in the next day or two we
can get the process stable enough to trim the reviewer list on the
github repo so that we don't accidentally get stray PRs going through.

I'll also update the WR repo documentation to note that it is now
dowstream of mozilla-central.

Please let me know if you have any questions or concerns, I'm happy to
help people with workflow problems.

Cheers,
kats

[1] https://wiki.mozilla.org/Platform/GFX/Quantum_Render#Try_pushes
[2] https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html

[Kartikaya Gupta]

Just to follow-up on this email - I wrote this a bit hastily yesterday
and it was mostly intended at the core team working on WR. Some of the
missing context here is:

- We will definitely still accept PRs on the github repo from
contributors, review them, and land them in m-c. I have updated the
text in the README file to reflect this [1]. Contributors who are
familiar with the m-c workflow should prefer to submit that way since
it's less work, but PRs on github are fine. If it's a pain point for
anybody to take a PR from github and land it on m-c I'm happy to do
that work - the scripts I was using before can be easily updated to do
this, and I can deploy it somewhere so it's as easy as "push a
button."

- We definitely want to continue to have WR building standalone, since
that benefits everybody. To prevent gecko dependencies from creeping
in, we are running CI jobs on treeherder as tier-1 [2] that build and
test webrender standalone. These are the same jobs that bors-servo
runs prior to merge (with the exception of the macOS jobs, which is
being tracked in bug 1516568 and that I will work on soon), so if
anybody tries to add gecko dependencies, it will cause bustage and
should get backed out before it hits m-c. If anybody can think of
other ways in which "WR standalone" could regress, please let me know
and we can try to find a way to guard against that.

- The plan for syncing changes from m-c to github is pretty simple: I
have a cron job that exports changes from m-c and applies them to
github, and then submits a PR to the github repository. It retains
authorship information; the only change it makes is to update the
commit message with the m-c revision so we can easily cross-reference
changes. The first one of these was [3] and merged this morning. I
will continue to manually r+ these PRs and let bors merge them until
I'm satisfied the script is stable. At that point I'd like to grant
reviewer bits to the moz-gfx bot so that it can self-r+ the PRs for
bors to merge. After that, I'd like to remove reviewer bits from
everybody else (or almost everybody) so that we reduce the risk of
accidentally merging PRs from the github side that are not the ones
syncing stuff from m-c. Note that in this workflow bors-servo will
still be the one actually pushing to master after verifying the merge
is green. I see no reason to remove this part of the workflow, and in
fact it will ensure that each incoming PR is good. At some point in
here we'll also move the script so it's running in the cloud instead
of my desktop.

That's basically it. I think I have a pretty good handle on the
details and possible error conditions, and if you're interested in
those feel free to reply to me directly.

[1] https://github.com/servo/webrender/commit/b912b0d02ef444464dc4494eadd11c22a9c9791a
[2] https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=webrender&revision=a51746f37520891be96522dbce8d1bade45d8b14&group_state=expanded
[3] https://github.com/servo/webrender/pull/3499