Reducing kernel-maintainer burnout

Posted Nov 29, 2023 12:26 UTC (Wed) by kleptog (subscriber, #1183)
In reply to: Reducing kernel-maintainer burnout by wtarreau
Parent article: Reducing kernel-maintainer burnout

> You start by suggesting something and you change your mind in the middle for something better, so you just want to s/foo/bar/g to replace all the variables prefixes.

I guess we mean different things by reviewing. Reviewing for me does not involve writing any code, the idea is to provide the submitter enough information to fix it themselves and resubmit.

Reducing kernel-maintainer burnout

Posted Nov 29, 2023 14:42 UTC (Wed) by wtarreau (subscriber, #51152) [Link]

> Reviewing for me does not involve writing any code, the idea is to provide the submitter enough information to fix it themselves and resubmit.

It's often much more efficient (and friendly) to write "I think maybe a better approach could be something around this:" and give the start of an example, than "no, still not what I'm expecting, try again". Look at reviews done on LKML, a non-negligible number of them suggest code snippets to discuss around. This is particularly true for bug fixes, where it's often a tradeoff and multiple approaches need to be explorated. That's precisely one of the reasons some tools are quite bad at this, when they don't allow the reviewer to express what they're thinking about, and cause many round trips.

Reducing kernel-maintainer burnout

Posted Nov 29, 2023 20:34 UTC (Wed) by viro (subscriber, #7872) [Link]

Alas, some of us just can't aspire to such heights of managerial Tao and feel an occasional urge to explain things, even at the expense of sullying the proper forms with actual details. Or believe that Lao Tzu had been taking the piss and those who take his teachings too seriously are utter wankers....

Reducing kernel-maintainer burnout

Posted Nov 30, 2023 11:48 UTC (Thu) by farnz (subscriber, #17727) [Link]

I often find myself wanting to quickly confirm that a suggestion I have is workable before I make it - I'm not infallible, but I can quickly write a small amount of code (ignoring error checking, ripple effects outside the area I'm changing, good style etc) to see what my suggestion will do to the code I'm reviewing. If I like what I see, I'll make the suggestion, while if I see that it's actually obfuscating the code, I'll not suggest it.

Reducing kernel-maintainer burnout

Posted Dec 4, 2023 14:02 UTC (Mon) by Hattifnattar (subscriber, #93737) [Link]

I would hate to get a review that just said "this line is wrong" without giving any reason, or "this function can be made more efficient" without any suggestion. Do you expect me to read your mind?

And a reason or a suggestion often involve, surprise-surprise, code.

Reviewing is just a conversation on a specific topic. The topic being code, it's entirely reasonable that the conversation will include code fragments...