Re: [PATCH 2/3] MAINTAINERS: Require kvm-xfstests smoke for ext4

On 11/22/23 18:17, Darrick J. Wong wrote:
> On Wed, Nov 22, 2023 at 04:44:58PM +0200, Nikolai Kondrashov wrote:
>> On 11/20/23 00:54, Theodore Ts'o wrote:
>> I already queued a switch to the kernel.org URL, which Darrick has suggested.
>> I'll drop it now, but you guys would have to figure it out between yourselves,
>> which one you want :D
>>
>> Personally, I agree that the one on GitHub is more reader-friendly, FWIW.
> 
> For xfstests-bld links, I'm ok with whichever domain Ted wants.

Great! I just hope I can keep track of all the requests :D

>>> And similarly, just because the V: line might say, "kvm-xfstests
>>> smoke", someone could certainly use kdevops if they wanted to.  So
>>> perhaps we need to be a bit clearer about what we expect the V: line
>>> to mean?
>>
>> I tried to handle some of that with the "subsets", so that you can run a wider
>> test suite and still pass the Tested-with: check. I think this has to be
>> balanced between allowing all the possible ways to run the tests and a
>> reasonable way to certify the commit was tested automatically.
>>
>> E.g. name the test "xfstests", and list all the ways it can be executed, thus
>> communicating that it should still say "Tested-with: xfstests" regardless of
>> the way. And if there is a smaller required subset, name it just "xfstests
>> smoke" and list all the ways it can be run, including the simplest
>> "kvm-xfstests smoke", but accept just "Tested-with: xfstests-smoke".
>>
>> I'm likely getting things wrong, but I hope you get what I'm trying to say.
> 
> Not entirely -- for drive-by contributions and obvious bugfixes, a quick
> "V: xfstests-bld: kvm-xfstests smoke" / "V: fstests: ./check -g smoke"
> run is probably sufficient.
> 
> (Insofar as n00bs running ./check isn't sufficient, but that's something
> that fstests needs to solve...)
> 
> For nontrivial code tidying, the author really ought to run the whole
> test suite.  It's still an open question as to whether xfs tidying
> should run the full fuzz suite too, since that increases the runtime
> from overnightish to a week.
> 
> For /new features/, the developer(s) ought to come up with a testing
> plan and run that by the community.  Eventually those will merge into
> fstests or ktest or wherever.

Of course, makes sense. Thank you!

Nick