Re: [PATCH] iomap: standardize tracepoint formatting and storage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

--D



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux