On Mon, Jan 30, 2017 at 6:23 PM, Gregory Szorc <g...@mozilla.com
> I'm glad you have rediscovered why project branches aren't great long-term
> solutions and that development should happen as close to mozilla-central as
> possible :)
It was never meant to be a long-term solution, but yes, the calculus
of costs vs benefits is shifting now and it makes sense to move it
closer to m-c.
>> As part of this, I would like to enable QR build jobs (which are
>> normal linux64/osx64/win64 builds with --enable-webrender in the
>> mozconfig) as tier-1, and linux64 QR test jobs as tier-2. I don't
>> expect that having the builds tier-1 would be a burden on platform
>> developers, as almost all of the new c++ code is compiled regardless
>> of the --enable-webrender flag, so developers will catch compile
>> errors with their usual workflow. Tests being tier-2 seems like an
>> acceptable compromise, as it doesn't block platform developers but
>> also gives us an early warning of changes that potentially affect QR.
>> In practice, most test failures we've experienced are simply new
>> reftests that need to be annotated with fails-if(webrender).
> This is basically what I did for Stylo in bug 1318200. Extending that
> solution to work for QR should be trivial. Although it appears from  that
> most of that work is already done on the graphics repo, just without build
> peer review.
Yeah, I made changes to the in-tree taskcluster configs in the
graphics branch that was roughly modeled after the stylo taskcluster
changes. I had to go a bit beyond stylo to get the win64 and macosx64
builds as well but the changes are roughly analogous.
> So, uh, you may want to verify your automation code matches
> what is used for Stylo before submitting that review request because if it
> doesn't, it will likely get r- and the review will be "make it more like
> what Stylo does."
I'm expecting that we might have to make minor tweaks to the
taskcluster configs based on the review comments but hopefully nothing
major. (And even if they are major, it's a one-time thing, I can deal
> When you say "linux64 QR test jobs," what exactly does that mean? Is there a
> new test harness for a new class of tests? Or, is this running a large
> subset of existing tests just with QR enabled? If so, which ones? (If we're
> running a variation of existing tests, we could run into capacity concerns.)
I just mean the existing test jobs that we've enabled to run on the
linux64 QR builds. No new harness. The tests we have enabled so far
can be seen at https://hg.mozilla.org/projects/graphics/file/12c5788aa7a0/taskcluster/ci/test/test-sets.yml#l72
(or take a look at the graphics branch on TH).
>> As QR builds would be tier-1, they would need to run on all
>> integration branches (including m-i and autoland), but I think QR test
>> jobs could be limited to running on m-c, to reduce the load on our
>> infra. Right now there's not a lot of QR test jobs anyway but we're
>> actively greening up more test suites and getting them running on the
>> QR builds.
> As Lawrence said, capacity could be problematic. Generally speaking, it is
> easier to scale Linux than Windows than OS X.
So far we're only running on tests on Linux because TaskCluster isn't
really working for the other desktop platforms. (At least not that I'm
> And, builds are easier to
> scale than tests because the number of machine hours spent running tests
> dwarfs time running builds. What I'm trying to say is that this may
> ultimately result with a tiered rollout where some platforms are higher
> tiered than others for capacity reasons.
That seems fair. We can prioritize test suites so that e.g. Linux runs
a larger set and Windows runs just the really graphics-critical ones.
But at the moment I have my hands full with just getting the Linux
suites turned on, so adding jobs on other platforms is probably at
least a month away.
>> If you're interested in more details on how we would go about doing
>> the merge, please see . Any comments or suggestions are welcome.
> My understanding of the development model on the graphics repo is that many
> of the commits were throwaway. If this is indeed the case and the history
> doesn't provide much value, I'd seriously consider introducing a single,
> non-merge changeset in mozilla-central for this "import" instead of
> polluting history with value-less changesets.
There aren't actually that many throwaway commits in the graphics
mercurial repo. Prior to using the graphics branch, we were doing
development on github, and that *did* have a lot of throwaway commits.
When I migrated the code from github to the graphics branch I squashed
it all into four commits (see bug 1317774). At this point we have ~320
non-merge commits on the graphics branch that would get merged over to
m-c, and I feel like the history there is mostly pretty useful to
> Also, you could consider going the model of Stylo, which will have commits
> cherry picked from upstream into mozilla-central without explicit merges.
> That keeps history in mozilla-central much cleaner.
I think the boat on keeping m-c free of merge commits is probably out
of the solar system by now :) Seriously though, I'm not sure what
value doing cherry-picks instead of merges would provide. It kind of
makes sense for Stylo because of the integration with upstream servo
and how commits have to be gated against both m-c and servo, but we
don't have that restriction for QR. I think merges are less work than
doing cherry-picks overall. I do plan on doing a few initial
cherry-picks of stuff like the taskcluster changes and build system
stuff, but that's more because it needs proper review from
non-graphics people. Once the initial merge is done I don't see any
value provided by cherry-picking.