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. Of course anything touching shared code (i.e. outside of the gvt/ subdir), or code which can't be disabled with Kconfig needs to follow our established review&testing procedures. So submission to intel-gfx, CI by patchwork, review per our standards. > * How do we handle fixes to GVT-g code? Do all fixes need to go via the > GVT-g mailing lists and review? We're bound to get GVT-g patches on > intel-gfx mailing list too. There's confusion already [1]. Mostly the > GVT-g changes come from GVT-g maintainers as pull requests. > > [1] https://patchwork.freedesktop.org/series/14000/ Atm the gvt mailing list is closed, and there's no maintainer entry for it either. I think Zhenyu just needs to hang out here on intel-gfx to catch these, and then pick any gvt/ fixes up himself. > * GVT-g related changes to i915 proper must be reviewed on intel-gfx > mailing list, and must either be applied to drm-intel directly, or get > an ack to be merged via GVT-g tree and pull requests. Ack. > * GVT-g needs to start annotating fixes with the Fixes: tags, preferably > also cc: stable when we get that far, so our fixes plumbing can figure > out which commits to backport. > > => GVT-g maintainers will take care of this. Either that, or they need to send -fixes pull requests your way. I think we could try out either approach, but yes in the end gvt maintainers need to own this. We (i915 team here) won't take care of that. > * Should GVT-g have a MAINTAINERS entry of its own? > > => https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40 > > +INTEL GVT-g DRIVERS (Intel GPU Virtualization) > +M: Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx> > +M: Zhi Wang <zhi.a.wang@xxxxxxxxx> > +L: igvt-g-dev@xxxxxxxxxxxx Need to make sure igvt-g-dev is open to non-subscribers first. Otherwise ack. > +L: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > +W: https://01.org/igvt-g > +T: git https://github.com/01org/gvt-linux.git > +S: Supported > +F: drivers/gpu/drm/i915/gvt/ > > I think we'll want to keep intel-gfx there, but mostly I think it's > fine for the usual GVT-g development to happen on igvt-g-dev only. +1 > * igvt-g-dev@xxxxxxxxxxxx needs to start accepting mails from > non-subscribers. > > => Work in progress. Definitely ;-) > * GVT-g needs to start paying more attention to compiler and sparse > warnings. > > => GVT-G maintainers will take care of this. > > * GVT-g could use some overview documentation under Documentation/gpu. Hm, should we have a TODO file in gvt for some of the issues raised? Otoh most things are fairly small issues, so should all be fixable before 4.10 freeze. > * GVT-g bug management. Do you have something set up already? Would be > great to be able to use https://bugs.freedesktop.org so we could > reassign between i915 and GVT-g. +1. > What did I forget/overlook? Nothing else crosses my mind, but I'm sure we'll discover more ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
