On Wed, Jan 16, 2019 at 11:41 PM Eric Anholt <eric@xxxxxxxxxx> wrote: > > Daniel Vetter <daniel.vetter@xxxxxxxx> writes: > > > Compared to the RFC[1] no changes to the patch itself, but igt moved > > forward a lot: > > > > - gitlab CI builds with: reduced configs/libraries, arm cross build > > and a sysroot build (should address all the build/cross platform > > concerns raised in the RFC discussions). > > > > - tests reorganized into subdirectories so that the i915-gem tests > > don't clog the main/shared tests directory anymore > > > > - quite a few more non-intel people contributing/reviewing/committing > > igt tests patches. > > > > I think this addresses all the concerns raised in the RFC discussions, > > and assuming there's enough Acks and no new issues that pop up, we can > > go ahead with this. > > > > 1: https://patchwork.kernel.org/patch/10648851/ > > Cc: Petri Latvala <petri.latvala@xxxxxxxxx> > > Cc: Arkadiusz Hiler <arkadiusz.hiler@xxxxxxxxx> > > Cc: Liviu Dudau <liviu.dudau@xxxxxxx> > > Cc: Sean Paul <sean@xxxxxxxxxx> > > Cc: Eric Anholt <eric@xxxxxxxxxx> > > Cc: Alex Deucher <alexander.deucher@xxxxxxx> > > Cc: Dave Airlie <airlied@xxxxxxxxxx> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > igt is a bit awkward to work in (the mailing list is very noisy with the > Intel CI being email-based instead of gitlab-based and most of the > traffic being Intel), but it's the right place to be putting shared > tests and hopefully that pain point goes away eventually using gitlab > MRs. I have a filter to mark all CI mails as read, to avoid the spam a bit. And then check it only when I merge a series. But yeah, it's pain. > I think there are going to be some interesting questions on how to deal > with things like KMS properties that aren't amenable to > chamelium/writeback-based testing. However, we should default to > requiring tests and only skip that when we agree collectively that > something isn't testable currently. Should I add a sentence clarifying this? We don't want to block features on a new unproven/unwritten testing approach (e.g. "write an entire vkms to test-drive that feature"), that doesn't make sense. -Daniel > > Reviewed-by: Eric Anholt <eric@xxxxxxxxxx> -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
