On Wed, Oct 02, 2024 at 03:10:14PM GMT, Jani Nikula wrote: > On Wed, 25 Sep 2024, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > On Wed, Sep 25, 2024 at 01:52:02PM GMT, Simona Vetter wrote: > >> I think for at least drm the consensus is clear, we won't have kunit tests > >> that splat. > > > > Where was that ever discussed? > > Well, where was it ever agreed that it's okay for drm kunit tests to > emit warnings? :p One policy is upstream, the other isn't. And it does seem like the consensus towards downstream patches and policies is pretty well established. And I wasn't the one claiming that there's a consensus to begin with, so I don't see why I should prove anything? > >> Personally I really don't see the point of unit tests that are > >> somewhere between unecessarily hard or outright too much pain to > >> deploy in a test rig: Either you don't run them (not great), or you > >> filter splats and might filter too much (not great either) or you > >> filter as little as possible and fight false positives (also kinda > >> suboptimal). > > > > Or you don't do any of that, and just rely on the canonical way to run > > kunit test and trust it's going to pass tests that do indeed pass, and > > fail / warn on those that don't. > > That still doesn't address code being tested emitting *unexpected* > warnings. Then make kunit report a warning / failure when there's an unexpected warning splat. At the end of the day, the discussion is that we already require for for each committer to: - Apply patches - Check for checkpatch issues - Solve potential conflicts - Make sure it compiles on three different architectures, with huge defconfigs - Make sure the unit tests still pass I'm not going to add "and grep through the output of those 1000-ish tests for a warning" to that list. Maxime
Attachment:
signature.asc
Description: PGP signature
