[Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Chris Wilson]

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