[igt-dev] [PATCH] drm/doc: Make igts for cross-driver stuff mandatory

[Daniel Vetter]

On Wed, Jan 16, 2019 at 11:41 PM Eric Anholt <eric at anholt.net> wrote:
>
> Daniel Vetter <daniel.vetter at ffwll.ch> 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 at intel.com>
> > Cc: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> > Cc: Liviu Dudau <liviu.dudau at arm.com>
> > Cc: Sean Paul <sean at poorly.run>
> > Cc: Eric Anholt <eric at anholt.net>
> > Cc: Alex Deucher <alexander.deucher at amd.com>
> > Cc: Dave Airlie <airlied at redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
>
> 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 at anholt.net>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch