archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <>
To: Matthew Wilcox <>
Cc: Christoph Hellwig <>,
	Dave Chinner <>,
	xfs <>,
	linux-fsdevel <>
Subject: Re: [PATCH] iomap: standardize tracepoint formatting and storage
Date: Sun, 22 Aug 2021 10:20:23 -0700	[thread overview]
Message-ID: <20210822172023.GZ12640@magnolia> (raw)
In-Reply-To: <>

On Sun, Aug 22, 2021 at 04:30:24AM +0100, Matthew Wilcox wrote:
> On Sat, Aug 21, 2021 at 07:32:23PM -0700, Darrick J. Wong wrote:
> > @@ -58,8 +58,7 @@ DECLARE_EVENT_CLASS(iomap_range_class,
> >  		__entry->offset = off;
> >  		__entry->length = len;
> >  	),
> > -	TP_printk("dev %d:%d ino 0x%llx size 0x%llx offset %lx "
> > -		  "length %x",
> > +	TP_printk("dev %d:%d ino 0x%llx size 0x%llx offset 0x%llx length 0x%llx",
> %#llx is one character shorter than 0x%llx ;-)

...and since you declined to add even a conditional review tag, this
patch will now sit in limbo for 2-3 days while I agonize over whether 1)
I should send a v2 patch with this minor stylistic thing changed and
hope that nobody objects to the v2, or worse, tells me I should go back
to v1; 2) hope that someone else won't be as picky and send a review; 3)
prepare myself for the inevitable DM that's coming about how I'm too
soft on reviewers; 4) wait the other inevitable DM about how I really
could exercise maintainer's prerogative to ignore the trivial style
complaints; and 5) brace for the other inevitable DM about how I really
shouldn't abandon the review process to ram code into the kernel just
because of stylistic complaints.

Yeah, I'm not going to abandon the established public process.
Requiring RVB even for maintainer patches is a useful check against
maintainers committing garbage to the repo.

But.  All five of these things keep happening every kernel cycle, and
it's dragging down my mental health.  To say nothing of the worldwide
disease, political unrest, and hostile weather.

**This** is the reason why I want to quit and never come back.

I enjoy every part of the process from requirements to implementation.
I enjoy discussing the design of algorithms, and I find it satisfying
even to rip things out to try other suggestions.

I don't enjoy revving patchsets repeatedly to try to find the magic
combination of printf formatting strings, comment massage, and helper
function placement golf that will get every patch through review.  This
is why I'm constantly stressed out about not being able to keep up with
all the demands being placed on me.  Experts' time should be spent on
solving tough problems, debugging the really nasty bugs, and coaching
less familiar people as they get up to speed.  Not this.

So I'm putting everyone on notice: If you care about stylistic problems
(and while I'm on my soapbox: cleaning up other parts of the codebase
that a patch touches only briefly) so strongly, then change my patch and
send it back to me.  Or change the snippets you want in the reply, and
state that you ack/review the patch on condition that the snippets are

Once I'm done with 5.15 merge patches, I would like to have a broader
discussion about xfs/iomap review policies, and have requested a session
at LPC for this purpose.

(And in case it wasn't clear: If you think a piece of code is so poorly
fitted to a problem that you want me to go back to the drawing board, I
am still completely happy to do that.)


  reply	other threads:[~2021-08-22 17:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-22  2:32 [PATCH] iomap: standardize tracepoint formatting and storage Darrick J. Wong
2021-08-22  3:30 ` Matthew Wilcox
2021-08-22 17:20   ` Darrick J. Wong [this message]
2021-08-23  7:05   ` Christoph Hellwig
2021-08-23  7:03 ` Christoph Hellwig
2021-08-23 22:08 ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210822172023.GZ12640@magnolia \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).