The Plan
The proposal is to move Moz2D into its own repository. We would use hg subrepos for this purpose, you can read more about this here (http://mercurial.selenic.com/wiki/Subrepository). In this page we'll attempt to list some of the upsides and downsides of this approach, as well as more detailed information on workflow and technical implementation.
Workflow
First of all each revision of m-c would be linked uniquely to a changeset inside Moz2D. When you do an hg pull -u that changeset will automatically be pulled in the correct portion of your m-c tree, so in essence nothing will change for someone who's workflow is along the lines of: 'hg pull -u' - build, and who doesn't work on code inside Moz2D. That is, it is very important to point out our intention here is that the workflow of those not involved in graphics should not be affected.
For someone who -is- working on code inside Moz2D they would be working on the Moz2D repository and expected to test there as well. They can do this work both 'in place' in the repo as part of their mozilla-central tree, or in a stand-alone checkout of Moz2D. When they're pushing their update to Moz2D that should trigger builds and tests on the Moz2D code from the Moz2D repository.
Integration with Central
As states before, a revision of m-c would be linked uniquely to a changeset inside Moz2D. This is very much the desired behavior to prevent hard to spot inconsistencies, and it's also enforced by mercurial subrepositories. We would then update mozilla-inbound (or central, depending on what people prefer), to the latest changeset of the Moz2D repository at a regular interval (for example once a day, if there are changes that day), that change would trigger a full mozilla-central build/testrun just as any other change to mozilla-central.
What to do on Test failures on central?
In the ideal world the Moz2D test-suite should be complete enough that no mozilla-central test failures will ensue. Should this not be the case the changeset will be backed out of m-c, moving m-c back to the 'last working' revision of Moz2D and the cause of the problem will be diagnosed and fixed on Moz2D, and a test added to the Moz2D test suite. Central would then be moved back onto the tip of the Moz2D repository and things would resume as normal.
What is the process if other bugs appear on central?
The normal process of bug diagnosis should then assume, normal bisection would of course work. However if a graphics bug is strongly suspected there's an interesting advantage to the subrepo setup, because bisecting -only- inside the Moz2D repository could be done a lot faster and with reduced, reliable rebuild times (i.e. only gfx and layout/media). Of course if the bug -is- found to be a bug in Moz2D it would be possible to move central back onto an earlier changeset of Moz2D if potential API additions allow this and depending on the severity of the bug.
What if a change spans central and Moz2D
In the rare case that a change has to span both Moz2D and central (for example an existing API change, rather than an addition), there will be two changesets, one will contain the changes to Moz2D. The new tip of Moz2D would then no longer be compatible with central, the changeset to central would then atomically contain both the API changes and the update of the Moz2D tagged revision. This would of course mean that a newer m-c could no longer be trivially be switched to an older revision of Moz2D, in this situation the normal workflow for backout would resume on mozilla-central (where the Moz2D tagged revision and API changes would be reverted).
What about Aurora/Beta/etc.?
One issue we'd need to solve along with this would be how to work with merges to aurora or beta. The most obvious choice would be to then create a branch on the Moz2D repository off the original revision aurora is referring too, and then pointing aurora to that branch. There's several other possibilities, however this is something that might be best worked out along the way. It should be noted that this isn't necessarily a downside but more of a change in process.
What does this buy us?
So there's several advantages to the graphics team for this approach, one would be the increased turnaround time on builds, as well as potentially increased turnaround times on try builds across platforms if we were to setup a try system for Moz2D. This in turn would also reduce the load on our infrastructure and in addition it would help speed up our development and allow Servo and Gecko to more easily share their rendering code. We hope that with the ability to simply checkout, build, and work with Moz2D we'll more easily draw external contributors/users to the project.
What will be an additional advantage is that the new workflow will force us to truly view Moz2D as a separate component, will prevent adding intentional or accidental dependencies on central. As well ad strongly encouraging us to provide solid test suites, both for performance and correctness. Which will in turn provide an improved environment for adding features and improving performance through microbenchmarking.
Any caveats?
There are also some downsides. We'll be using a piece of functionality which has never been used inside Mozilla before, and almost certainly we'll run into one issue or the other somewhere along the way which we'll have to solve. Another consequence is that if somebody pulls, goes offline, and then update later, that update could fail if it requires a more recent changeset of the Moz2D repository. This situation will probably be rare though.