Merging to m-c discussion

[Kartikaya Gupta]

There's a number of topics we need to deal with to get the graphics
branch merged to m-c:

I) Reviews of code and merge process

This is going pretty well. Almost all of the audits in Phabricator are
taken care of. There's a bunch of code outside of gfx/ (specifically
the build changes for webrender, and the taskcluster config changes)
that will need external review before the merge. I'm thinking we can
do something like this:

a) Land all the rust code (webrender_bindings crate and all its
dependencies) into m-c. This is needed for step (b)
b) Land the build system changes into m-c with build peer review,
which adds the --enable-webrender flag. This is needed for step (c)
c) Land the taskcluster config changes on m-c with taskcluster peer
review. This will enable "QR" builds on m-c although at this point
they will be exactly the same as normal builds, but with more unused
rust code.
d) Merge m-c to graphics. The changes above will be in both trees and
merging them should basically be a no-op.
e) Merge graphics to m-c. This will get all the C++ code changes (in
gfx/, dom/ipc/, widget/ etc) as well as the reftest.list updates and
everything else. After this step the QR builds on m-c will actually be
using webrender.

I checked the size of the m-c hg repo with and without the graphics
branch changes, and the difference was negligible. So I don't think we
need to try and "strip out bad history" from the graphics branch where
we had things like an extra copy of freetype source in the tree. Just
doing a straight-up merge from graphics to m-c is probably the way to
go.

II) Automation/testing

Merging graphics to m-c means we'll start doing QR builds and tests on
all integration trees as well. This potentially adds to a lot of extra
machine time, specially if we want to run all the suites. Right now
we're only doing linux64 but eventually we'll want to do other
platforms which is even more stress on our automation capacity.

One way to solve this is to make --enable-webrender the default
configuration. However that means everybody will be building with
webrender which can slow down build times, increase binary sizes, etc.
I don't think we're anywhere near ready to do this yet.

Another option is to just run the tests on m-c instead of also doing
it on m-i or autoland. That effectively means QR tests will be tier-2
and we'll be on the hook to keep them green in the face of other
people's changes. That's no worse than what we have now, and is
probably my preferred approach right now.

III) Post-merge workflow

This is mostly a bunch of open questions:
- do we want to continue doing post-landing reviews? I'm thinking yes,
but restricting it to the more trivial reviews
- do we want to do daily merges from the graphics branch back to m-c?
I don't know. We could do it at a lower frequency, like once a week,
if we wanted to.
- do we want the sheriffs to take over sheriffing the graphics branch?
It will probably mean more aggressive backouts but also less work for
us to keep an eye on the tree state.

Any other thoughts/comments/concerns?

Cheers,
kats

[Kartikaya Gupta]

FYI unless anybody voices objections, I intend to send an email next
week to dev-tree-managment/dev-platform to hash out the details with
the sheriffs and get their blessing. I intend to propose that we
continue sheriffing the graphics branch ourselves, and we will do
merges from graphics to m-c on an ad-hoc basis (roughly weekly, or if
there are changes with high risk of conflicts that it makes sense to
merge sooner). Also I'd like to have QR builds tier-1 on m-c and
integration branches, while the tests will be tier-2 and run on m-c
only (in addition to the graphics branch). This is basically an
incremental improvement from where are now, and gets us halfway to
being a proper integration branch.

Cheers,
kats