On Thu, Oct 20, 2016 at 05:42:37PM +0800, Zhenyu Wang wrote: > On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote: > > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote: > > > > > > We need to formalize the process between i915 proper and GVT-g a bit > > > more, and address some of the current shortcomings and issues in the > > > process and GVT-g CI. > > > > > > This started off internally as a random list of items, I'm including > > > some of the current status as well. Please comment, as some of the stuff > > > here are just my opinions. > > > > > > * How do we ensure GVT-g patches get the same kind of pre-merge CI > > > coverage as we have for other i915 code? Could we at least make CI run > > > tests on GVT-g pull requests before merging to drm-intel trees? > > > > > > => Work in progress to set up GVT-g CI. > > > > Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want > > to do that then it's fine, but otherwise I'm leaning towards treating gvt > > like a sub-driver, with its own flavour of testing and review standards. > > > > Normally GVT-g shouldn't impact drm-intel CI. I do like to setup GVT-g specific > CI with fancy multiple VMs auto test available. But it might need some time > for QA team to setup that way. The problem is that gvt is a consumer of our APIs. When I change those I need reassurance that gvt does not break. We also need reassurance that when we backmerge from upstream changes to the hva do not break gvt. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
