Re: [PATCH 1/3] edid-decode: Introduce libedid-decode wrapper

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Wed, 9 Mar 2022 17:00:37 +0100
Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:

> Hi Pekka,
> 
> On 3/9/22 16:57, Pekka Paalanen wrote:
> > On Wed, 9 Mar 2022 15:45:29 +0100
> > Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >   

...

> >> CI is already done: it's build every day together with the kernel media code
> >> and v4l-utils in my daily build. Results of that are posted on the linux-media
> >> mailinglist.  
> > 
> > Nice, but that is after merging patches, right? I was thinking
> > pre-merge.  
> 
> Not sure what useful pre-merge testing can be done other than just running 'make' :-)

To ensure that patches that are not intended to change the output
indeed do not change the output, or do not introduce crashes. Other
popular tests are checking for compiler warnings against a specific
compiler version, and commit messages e.g. for S-o-b if that's used.

For example wayland-scanner (a code generator) has tests in the Wayland
test suite that verify the output for certain test inputs does not
change. The test inputs and reference outputs are committed into git.
If a patch intentionally changes the output, then that patch also
includes changes to the reference output files. Simply reading a patch
will also show how the output changed.

But your test corpus is huge, and this method does not scale up to that
directly. You could maybe have a few chosen test EDIDs for this, but
running the full corpus needs something quite different. Maybe the full
corpus is best the way you do it now.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]