That's debatable. Arguably they shouldn't be building w/ proprietary codecs enabled, because that flag isn't on by default.

Some of the bots in question are mirrored into trybots (linux_chromium_rel_ng, win7_chromium_rel_ng) which already build the proprietary codecs because they run GPU tests, which require them. The Chromium recipe used to enforce consistent configurations between the waterfall bots and trybots but that enforcement was lost when these configurations moved src-side into mb.

It's urgent that these bots build with the proprietary codecs because we are missing both waterfall and trybot coverage for CLs which can cause build breakage per  Issue 867520 .

As I noted before, if you enable the flag everywhere, then you will *also* miss coverage, and that's not okay either.

I don't think we ever actually enforced matching GN args / GYP_DEFINES between trybots and waterfall bots, because of the whole "enable dcheck or not" issue.

I'm sorry, my comment in #c1 was ambiguous. To clarify: I'm okay with some builders having proprietary_codecs enabled. I'm not okay with all of them having it enabled.

I'm turning on proprietary codecs for a few specific builders, not all of them.

The Chromium continuous builders, which require that the codecs *not* be included, are *not* being changed. I'm adding new mb mixins, not modifying the behavior of existing ones, and changing a few builders to point to the new mixins.

cross-posting from https://chromium-review.googlesource.com/c/chromium/src/+/1150450#message-e12e160b53c0cdd9796e675e7ec765d9f1882388 for completeness:

kbr@ and I talked this through offline. 

We'll set proprietary_codecs=true on the builders on the existing chromium waterfalls, to better match the GPU builders, and we'll set the flag also on the trybots in the CQ.

However, I don't want to lose coverage of the proprietary_codecs=false debug configuration completely, so we'll spin up some new continuous-only debug builders that will not be part of the CQ. Breakages specific to that configuration should be rare, so I think that'll be okay. If it isn't, we can add them to the CQ as well. That'll be done in a separate CL.

We already have and will continue to have release proprietary_codecs=false coverage via the builders on the "chromium" waterfall.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6c83d21be6b04b9b8a534989326309c3ff3c4e3f

commit 6c83d21be6b04b9b8a534989326309c3ff3c4e3f
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Jul 27 20:52:59 2018

Compile proprietary codecs on more builders and trybots.

These bots weren't building with these codecs and should have been. In
at least one case (Win Builder), the fact that the waterfall bot wasn't
building with the codecs represented a mismatch in configuration between
the waterfall bot and trybot.

This CL affects the configurations of the following machines:

  chromium.linux:Linux Builder (dbg)
  chromium.linux:Linux Builder (dbg)(32)
  chromium.linux:Linux Builder
  chromium.mac:Mac Builder (dbg)
  chromium.win:Win Builder
  chromium.win:Win Builder (dbg)
  chromium.win:Win x64 Builder
  chromium.win:Win x64 Builder (dbg)
  tryserver.chromium.linux:linux_chromium_dbg_32_ng
  tryserver.chromium.linux:linux_chromium_dbg_ng
  tryserver.chromium.mac:mac_chromium_compile_dbg_ng
  tryserver.chromium.mac:mac_chromium_dbg_ng
  tryserver.chromium.win:win10_chromium_x64_dbg_ng
  tryserver.chromium.win:win10_chromium_x64_rel_ng
  tryserver.chromium.win:win_chromium_compile_dbg_ng
  tryserver.chromium.win:win_chromium_dbg_ng
  tryserver.chromium.win:win_chromium_x64_rel_ng

Bug:  867536 
Change-Id: I04584548cb903df49ab1071535612ea151310c88
Reviewed-on: https://chromium-review.googlesource.com/1150450
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578766}
[modify] https://crrev.com/6c83d21be6b04b9b8a534989326309c3ff3c4e3f/testing/buildbot/chromium.win.json
[modify] https://crrev.com/6c83d21be6b04b9b8a534989326309c3ff3c4e3f/testing/buildbot/test_suite_exceptions.pyl
[modify] https://crrev.com/6c83d21be6b04b9b8a534989326309c3ff3c4e3f/tools/mb/mb_config.pyl

The CL above enables the proprietary codecs on some key waterfall bots and trybots. Need help from the WebRTC team on Issue 868082 to enable the H.264 code path for some test suites on some of the bots which were broken by that change.

WebRtcCaptureFromElementBrowserTest.VerifyCanvasCaptureOffscreenCanvasFrames is flaky in viz_content_browsertests on win10_chromium_x64_rel_ng after my change:

https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win10_chromium_x64_rel_ng/59988

Passing --disable-features=WebRTC-H264WithOpenH264FFmpeg to viz_content_browsertests on Win10 Tests x64 in response.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f3e8a3f52a8270f98567a6149d845e3cf8ba02e9

commit f3e8a3f52a8270f98567a6149d845e3cf8ba02e9
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Jul 28 02:44:12 2018

Disable WebRTC-H264 for viz_content_browsertests on Win10 x64.

Pass --disable-features=WebRTC-H264WithOpenH264FFmpeg to
viz_content_browsertests on "chromium.win:Win10 Tests x64" similarly
to how it's being done for content_browsertests.

Tbr: dpranke@chromium.org
Bug:  867536 
Change-Id: Ib04e95a3b1dd94b29027f7cda26b5780e1a16a92
Reviewed-on: https://chromium-review.googlesource.com/1154141
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578901}
[modify] https://crrev.com/f3e8a3f52a8270f98567a6149d845e3cf8ba02e9/testing/buildbot/chromium.win.json
[modify] https://crrev.com/f3e8a3f52a8270f98567a6149d845e3cf8ba02e9/testing/buildbot/test_suite_exceptions.pyl