On Wed, Oct 25, 2023 at 08:13:25PM -0700, Darrick J. Wong wrote: > 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. Sounds good. > 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. Ok, cool. > That part isn't changing. I've enjoyed working with you and hope > that'll continue well into the future. :) Thanks. That's good to hear and right back at you. > > > 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! Yes. > > > 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. :) In that case I would propose you send a patch to Linus for MAINTAINERS updating the tree and the entries for iomap. I believe it's customary for the current maintainer to do this. Thanks! Christian
