Re: [GIT PULL] iomap: bug fixes for 6.6-rc7

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Oct 26, 2023 at 01:54:29PM +0200, Christian Brauner wrote:
> 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@kernel.org> 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.

Thank you!  I enjoyed reading that! :)

> > 
> > > 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.

Will do.  I'll change the M: entry to you, and add myself as an R:.

--D

> 
> Thanks!
> Christian