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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux