nxia@: betty-pre-cq was the only one with VMTest coverage. If we want to restrict betty-pre-cq, we may need to move VMTest coverage.

+ihf who was involved in a lot of the juggling recently.

+nxia for expert opinion

Yes, we should run betty only on the kernel changes it tests (currently 4.4, but may change in a year or two).

I'll let Richard / Aviv do this juggling because they're acting as the infra side gatekeepers of coverage. ihf@ has spoken and has a lot of knowledge from the product side.

Let's do this sooner than later because we're wasting resources, and annoying developers.

The mechanism for "don't test betty for certain changes" is to
add a COMMIT-QUEUE.ini to the target repo.

In this case, the file already exists, and by all appearances,
none of the kernel branches run betty, even v4.4(!).  However,
from bug 752768, we see this CL:
    https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/607932/

That's a v3.8 kernel CL, and it's pretty clearly running the
default pre-cq builders, not the builder configured in
kernel/v3.8/COMMIT-QUEUE.ini.  I can't explain that.

So, there's something wrong/unexpected in the commit queue
handling for the kernel repos.  This goes beyond what I know
how to explain or fix.

Passing to nxia@ in hopes she can explain why the COMMIT-QUEUE.ini file
for src/third_party/kernel/v3.8 didn't apply to this CL:
    https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/607932/