> My overall concern, and I think the other guys doing this for virt > drivers will agree, is trying to scope down the exposure to unrelated > failures.
But, if it's not related to your driver, then it also failed in the upstream gate, right? If it didn't fail the upstream gate, then it is some weird interaction. Of course, for spurious failures, you'll still have the case where you recheck something and it passes the next time, but that's exactly what we have today. I don't see a new CI job for a given driver being a "monstrous" amount of work above and beyond what we have to do today to triage the issues. Of course, driver CI is not a single-time task that you never have to babysit... I think that running as close as possible to the upstream gate is crucial for us to gain the level of comfort we have with the stuff that is actually tested upstream. If you pass more often because you don't include any of the tests you don't strictly have to run, and don't have a set of folks ready to triage failures, then you don't have quality parity with the other stuff. That's kinda the whole point of us doing this, no? --Dan _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
