On Sun, Mar 2, 2025 at 2:50 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > 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. No, it didn't affect btrfs, because -L exists for mkfs.btrfs and it's used to set a label, which makes the test run fine. > 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. Probably so, because I have the feeling that most of the time there's no testing for btrfs (and it seems ext4 too) when for-next is updated. > 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
