On Tue, Oct 24, 2023 at 01:47:17PM +0200, Christian Brauner wrote: > On Mon, Oct 23, 2023 at 03:38:10PM -0700, Darrick J. Wong wrote: > > On Sat, Oct 21, 2023 at 09:46:35AM -0700, Linus Torvalds wrote: > > > On Fri, 20 Oct 2023 at 23:27, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > > > > > Please pull this branch with changes for iomap for 6.6-rc7. > > > > > > > > As usual, I did a test-merge with the main upstream branch as of a few > > > > minutes ago, and didn't see any conflicts. Please let me know if you > > > > encounter any problems. > > > > > > .. and as usual, the branch you point to does not actually exist. > > > > > > Because you *again* pointed to the wrong tree. > > > > > > This time I remembered what the mistake was last time, and picked out > > > the right tree by hand, but *please* just fix your completely broken > > > scripts or workflow. > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git iomap-6.6-fixes-5 > > > > > > No. > > > > > > It's pub/scm/fs/xfs/xfs-linux, once again. > > > > Sorry about that. After reviewing the output of git request-pull, I > > have learned that if you provide a $url argument that does not point to > > a repo containing $start, it will print a warning to stderr and emit a > > garbage pull request to stdout anyway. No --force required or anything. > > Piping stdout to mutt without checking the return code is therefore a > > bad idea. > > > > I have now updated my wrapper script to buffer the entire pull request > > contents and check the return value before proceeding. > > > > It is a poor workman who blames his tools, so I declare publicly that > > you have an idiot for a maintainer. > > > > Christian: Do you have the bandwidth to take over fs/iomap/? > > If this helps you I will take iomap over but only if you and Christoph > stay around as main reviewers. I can't speak for Christoph, but I am very much willing to continue developing patches for fs/iomap, running the QA farm to make sure it's working properly, and reviewing everyone else's patches. Same as I do now. What I would like to concentrate on in the future are: (a) improving documentation and cleanups that other fs maintainers have been asking for and I haven't had time to work on (b) helping interested fs maintainers port their fs to iomap for better performance (c) figuring out how to integrate smoothly with things like fsverity and fscrypt (d) not stepping on *your* toes every time you want to change something in the vfs only to have it collide with iomap changes that you didn't see Similar to what we just did with XFS, I propose breaking up the iomap Maintainer role into pieces that are more manageable by a single person. As RM, all you'd have to do is integrate reviewed patches and pull requests into one of your work branches. That gives you final say over what goes in and how it goes in, instead of letting branches collide in for-next without warning. You can still forward on the review requests and bug reports to me. That part isn't changing. I've enjoyed working with you and hope that'll continue well into the future. :) > There's not much point in me pretending I > can meaningfully review fs/iomap/ and I don't have the bandwith even if > I could. So not without clear reviewers. I hope the above assuades your concerns/fears! > But, - and I'm sorry if I may overstep bounds a little bit - I think > this self-castigation is really unwarranted. And we all very much know > that you definitely aren't an idiot. And personally I think we shouldn't > give the impression that we expect this sort of repentance when we make > mistakes. > > In other words, if the sole reason you're proposing this is an > objectively false belief then I would suggest to reconsider. Quite the opposite, these are changes that I've been wanting to make for months. :) --D
