On Tue, Nov 26, 2013 at 9:02 PM, Ben Widawsky <ben@xxxxxxxxxxxx> wrote: >> The problem is that generating the testlist (or printing the commands) >> is a feature QA actually relies on. I also use it occasionally to >> quickly test igt library changes. So we can't bail that early. My >> patch bails fairly late, but I didn't see a better spot. >> -Daniel > > I'm confused then about how this really improves my current situation. Quick recap of our irc discussion: I guess I'm trying to solve a slightly different problem, assuming that we always want some kind of test result. Hence everything fails (as of v2) and the result json contains the reason. I think that's the right thing to do for regression testing in a lab-like setting. For developers I guess a little script or so some option to yell louder and faster than this here could still be useful. Otoh there'll always be test-specific failure modes (like runtime pm not configured properly) and imo it doesn't make much sense to filter for all of them beforehand. And otherwise I kinda expect that people will cook their own scripts anyway to kill X, Wayland and a bunch of deamons that get in the way and then run piglit with a few default options. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
