Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23

["Theodore Ts'o" <tytso@mit.edu>]

On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> Or another example, a fix from Ted, for a generic test case that
> always failed on ext4:
> 
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
>

Actually, this fixed a bug which affected file systems for all file
systems *except* xfs, since the generic bug was injecting an
XFS-specific mkfs option into _scratch_mkfs.  This was a *really*
obvious bug, but the problem was that commit 000813899afb ("fstests:
scale some tests for high CPU count sanity") made *huge* number of
changes, which made it hard to review the change, and also made it
harder for Dave to rebase the change, which is why, apparently,
pressure was applied to merge commit 000813899afb right before Dave
diappeared on vacation for a month.  This is why I nated that there
appeared to be a double standarrd in place; I can't help but suspect
that if anyone *else* had sent in this commit, it would have been
rejected.

As far as testing, my understanding is that the huge amount of testing
happens between the promotion from for-next to the master branch.
This is why I used to make a point of upgrading my test appliance to
for-next, so I could help point out problems before most other
deveopers would see it in the master branch.

The fixes that you pointed out was all reasons why the master branch
hadn't been updated in months; it was because for-next still had
breakages.  There is the challenge that when master hasn't gotten
updated for 2 or 3 months, it becomes harder to tell whether a test
failure was caused by a test bug, or a kernel bug.  (It's not
impossible; for a while I was going to older versions of for-next, and
the comparing the results to newer versions of for-next, and then
filtering out new tests, but it's a bit of a pain.)

Ultimately, like most engineering tradeoffs this was a pain allocation
exercise.  Dave didn't want to deal with rebasing changes, so the
check-parallel changes got merged to for-next early.  This inflicted
pain on other xfstests developers.

					- Ted