On Wed, Apr 24, 2024 at 02:14:36PM +0200, David Sterba wrote: > On Wed, Apr 24, 2024 at 05:12:43PM +0800, Zorro Lang wrote: > > On Wed, Apr 24, 2024 at 06:06:43AM +0800, Anand Jain wrote: > > > (I just realized that the previous attempt to send this PR failed. Resending it now.) > > > > > > Zorro, > > > > > > Several of the btrfs test cases were failing due to a change in the golden > > > output. The commits here fix them. These patches are on top of the last PR > > > branch staged-20240414. > > > > Hi Anand, > > > > I found lots of patches in this branch doesn't have RVB. That's not safe, if > > we always do things like that. We need one single peer review at least, that > > requirement is low enough I think. > > > > Better to ping btrfs-list or fstests-list or particular reviewers to get > > review, if some patches missed RVB. > > Anand is maintainer within fstests and I guess he reviews the patches > when putting them to the branch for merge. Filipe is mentioned as > reviewer but please don't expect him to reivew each and every patch. Hi David, Sure, mostly I trust the pull request from Anand. But this time those patches are from himself, can we say "I've reviewed the patches from myself"? Is that an acceptable work process? In other words, should maintainers have the privilege to merge his own patches without any other review? I'm a bit confused, if that's acceptable by all of you, especially we just through the "xz backdoor". > > I have a feeling that you're following process of merging patches that > is maybe modeled after linux kernel, with the multiple branches and > even merge window (mentioned in previsous PR), but this is IMO > inadequate for a testsuite where we need quick fixups to test cases to > be released in a much shorter turnaround. I try to learn it, but won't follow it totally. Due to fstests is not linux project, it's small and fast, we can accept quick fixes, but not without control. I'm not removing all the patches from his PR. I've merged those patches which got reviewed. For those un-reviewed patches, I'll try to deal with them in these 2 days, and try to help to catch the next release. > > I was expecting that if there was a dedicated maintainer for a > filesystem then things would go smoothly and we could skip formalities > because the maintainer is expected to do reviews that count too. Anand is already particular for btrfs part of fstests. But this time the patches are from him. Anyway, I'll help to review his patches, and merge them if no more other opinions from btrfs-list. Thanks, Zorro >
