Can you clarify the main motivation behind using a subrepo over a Tier 1 dev branch like m-i or services-central? Mimicking what we already do elsewhere would have less process/infra change overhead, and my intuition tells me that per-checkin builds/tests could be configured specifically for that repo. Perhaps we should be focusing mostly on your point about "Improv[ing] sharing between Servo/Gecko" though.
Assuming we move forward with a subrepo, a few thoughts: * Whatever the branching model becomes, it sounds like it'll end up being around merges. Just let us know what you'd like us to do at m-c->m-a and upon subsequent merges. No problem there. * We'll need to decide how to handle approvals - whether to gate at landing to a branched subrepo, or updating the changeset in the main repo. Just requires some discussion. * Somebody (engineer, sheriff) would need to make sure that after landing to a subrepo branch, a version of Firefox is marked as fixed once it the changeset starts being referenced from the main repo. As for impact to QA and investigations, I agree that the change should be fairly minimal. Since we'd still like the help of contributors and QA in bisecting a day's worth of Moz2D changes, new documentation may be necessary. -Alex On Mar 27, 2013, at 1:42 PM, Bas Schouten <bschou...@mozilla.com> wrote: > Hi all, > > Over the past year we've increased our dependencies on Moz2D (formerly known > under the codename Azure), our new 2D rendering API. Currently we're using it > for canvas drawing on all platforms and content drawing on Windows where > using Direct2D, and in the near future we will be moving to using it for > content on all platforms. > > From the very beginning of Moz2D development we've taken care to make sure it > can be built outside of the rest of Gecko, having only dependencies on > several MFBT headers. This was done to reduce the barrier for external usage > and development, we've since seen this benefit us for example in Servo using > Moz2D as well. In addition to that it has helped development and bugfixing by > having a much faster workflow for building/testing with which bugs could be > located and fixes created. > > Going forward we're expanding on that by ensuring the stand-alone builds and > works on all platforms and becomes the defacto way of the 'first level' of > testing when implementing new features or fixing bugs in Moz2D. In addition > to that we're expanding on our existing stand-alone unittesting suite as well > as adding a peformance testing suite, which will include microbenchmarking > and support measuring performance on Moz2D drawing recordings (single-page > recording support has just landed on mozilla-inbound). > > When moving forward we have several goals for Moz2D when it comes to the > workflow: > > - Improve Moz2D development workflow by having faster turnaround time on > builds and tests (both local and Try) > - Lower the barrier for external contributors, some people have already > expressed the desire to work on potential backends we do not wish to invest > in ourselves, but have been deterred by the complexity of the > checkout/building process. > - Improve sharing between Servo/Gecko. > - Reduce load on our infrastructure by building and testing only Moz2D > stand-alone when a change affects only Moz2D, both on regular builds and try. > > As the next step in moving towards these goals and optimally supporting them > 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). The intention is that this > will be done in such a way that the workflow for developers not involved in > Moz2D development would essentially not change. > > A more detailed description of the proposal and the workflows involved can be > found here (https://wiki.mozilla.org/Platform/GFX/Moz2DSubrepository) for > those interested in the details. Since we believe if we go through with this > it would be the first time we use a true subrepository system for a component > used in mozilla-central, we'd very much appreciate any thoughts or feedback > people might have on the idea. > > Best regards, > Bas > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
