On Wed, Dec 11, 2013 at 7:04 PM, Volkin, Bradley D <bradley.d.volkin@xxxxxxxxx> wrote: >> We unfortunately don't really have tons of spare cycles from our QA team >> for testing branches (pretty much none actually), so the usual approach is >> to review and merge patches without first going through QA. If we pull in >> your new i-g-ts first we should have decent assurance that nothing blows >> up. And since kernel patch series should always be fully bisectable we can >> stop at any point in time if something goes wrong. > > Ok, sounds good. I'm fine with whatever approach gets us the test coverage soonest. One thing that's always important is to get tangential prep work to the beginning of your patch series as much as possible. That way we can merge&test those glue patches (and their impact on the rest of the driver) even when review is blocked on some contentious topic that affects the core of a new feature. -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
