The more I dig through kernel mailing list discussions, the more I think that we would do well to end the use of "NAK" entirely. It is an exercise of power that is hurtful to read and gets in the way of an actual discussion of how a patch needs to be improved. I have, in my maintainer role, never said "NAK" to a patch and plan to continue that way.

*Edited* since people are asking: NAK (or NACK) comes (I believe) from the ASCII negative-acknowledge character. In this context, is an abrupt way for a maintainer to reject a patch.

@corbet who use it: the reviewers or the person posting the patch for review?

@corbet I disagree profoundly. It's very important to prevent things that will cause issues from getting in to the kernel, and a simple no is not always clear enough. And it comes up rather more often thank you'd think.

I mean Kent's behaviour is beyond the pale on any level, if this is in any way calibrated to that - that is not what a nack should be.

I agree on trying to communicate effectively and nicely, and I know I get this wrong sometimes myself (I will occasionally respond to my own email apologetically after I realise I perhaps came across unintentionally harshly).

But if you have a scenario like mm where things get merged unless people say no, sometimes you need to make it _very_ clear.

You sometimes have cases where the submitter is stubbornly refusing to listen to reason or the conversation goes around in a circle as well which can be problematic.

I guess I'd say 'no NACK _without_ a reasonable justification + if the series can be recovered, some constructive feedback as to how to get to an acceptable point'.

@corbet Any specific example that triggered this?

@corbet fwiw, I tend to not use it unless the message really isn't getting across.

@brauner I'm digging through the whole Asahi Lina graphics driver story, but it's something I've often thought.

@corbet yeah same, it just tends to be a signal for communication breakdown. usually because people are fixated on the specific patch and there's no discussions about the higher levels, like whether there's an actual problem, what the problem exactly is and isn't, then eventually what the design and architectural options are and which are good tradeoff choices, to finally maybe reach an actual patch.

still one of the best guides imo to do better https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/

@corbet the other case tends to be overloaded maintainers who failed to write documentation they could point at, and instead continue to just NAK patches because that's less typing. in the short term only, it's definitely a lot more typing long term

@jwf NAK (or NACK) - negative acknowledge - is a curt way of saying that a patch will be rejected.

@jani @corbet @brauner I've sent mails (perhaps privately, I can't remember), stating any use of NAKs is not productive, and that I would cease pulling stuff from NAK senders unless the next set of patches they submitted were documentation on the area they NAK'ed patches in. We have gotten some documentation as a result.

@airlied @jani @corbet @brauner yeah we did get into this. it's just that damage done is visible forever, and improving documentation to the point where you can just paste a kerneldoc link where previously people felt like dropping a NAK takes a long time

@corbet (For a moment I convinced myself that in Monty Python and The Holy Grail there was a scene about the "Knights who say Nak" and that this was in reference to that)

@pkal Heh ... one could have a *lot* of fun playing with that idea...

@corbet Trying to follow, but I'm out of the loop on the meaning of the acronym. Can anyone fill me in? Thanks!

@corbet I got my first ever NAK today from one subsystem, that ended up causing a rewrite based on that, and the actual subsystem I'm fixing doesn't like that solution, so I'm going back to the first ever version :)

@corbet oh, and it was merely exposing a symbol but I guess they didn't like it "for some reason"

@corbet May I ask what NAK means?

@brauner @corbet I use it (sparingly) for innocent-looking but buggy patches, to make sure they are not applied by a maintainer who didn't get a morning coffee.

@brauner @corbet And in these days where not all emails may reach the maintainer's inbox ("Bounce probe for ..."): "b4 am" picks up NAKs, unlike weaker review comments.

@june @corbet If it’s similar to Wayland protocol discussion terminology, then it means “not acknowledge”. I think it’s basically a veto vote, but I could be wrong, as I haven’t looked at either the LKML (Linux kernel mailing list) or the Wayland protocol discussions a lot, so take it with a grain of salt.

@corbet @pkal Are you sure it's not the Knights who write C?
C!

@marnanel @brauner The case that brought this to mind is https://lwn.net/ml/all/cd788ccf-0cf1-85d5-1bf8-efc259bd7e11@amd.com/

...more details on LWN shortly...

@sima @airlied @jani @corbet @brauner This is also something I'm simmered about in other areas. It seems like "NAK" gets easily abused (not just in Linux, but in other projects that have a similar process), and almost every example I've seen of it has resulted in a sour ending for all parties involved.

I find myself wondering if the NAK power should be actively eliminated in projects where it has resulted in an overly negative view of engaging with the project.

@Conan_Kudo @airlied @jani @corbet @brauner for me that generalizes to one of the most important lessons I've learned as a leader of some project or area

the more power you have, whether formal or informal doesn't really matter, the harder it is to actually use it. a big hammer is a very blunt instrument, and so the longer I do this, the more I just drop suggestions and help dig through tricky corners and get the consensus engineering started, but rarely ever finish to a solid conclusion

@sima @airlied @jani @corbet @brauner This makes sense to me. There are many areas where I have tremendous "power" (or at least the appearance of it), so I take great pains to demonstratively *not* use it. Contributors seem to appreciate that a lot, because the end result is that they feel valued across the board.

@Conan_Kudo @sima @airlied @jani @corbet @brauner Personally, the notion of using a "NAK" only makes sense if you see the project as your own property you want to protect from allegedly "wrong ideas".

So once you start to treat a project as a collaborative space with equal footing for everybody, it makes no sense to "NAK" anymore, because you recognized that you are not the owner, you are merely a manager of various contributors and make sure that people get their stuff done and to provide help

@jani @karolherbst @Conan_Kudo @airlied @corbet @brauner yeah ...

and right at this moment I'm pondering whether I should type up a comment, or not, as subsystem maintainer

deleted a draft twice already

@sima @jani @Conan_Kudo @airlied @corbet @brauner You can always ask others for advise if you are not happy with your drafts, but you should know that already 🙃

But anyway, I'm sure others are willing to help with those kind of responses.

@karolherbst @jani @Conan_Kudo @airlied @corbet @brauner oh sure

the question I'm pondering is how much should I talk about what has happened the past years in private discussions, or whether that's going to cause more damage than good

@sima @jani @Conan_Kudo @airlied @corbet @brauner oh you meant here in this discussion? Ah yeah...

@karolherbst @jani @Conan_Kudo @airlied @corbet @brauner nah like either as an lwn comment or maybe I should warm up the blog engine and draft some proper text

put the energy into commenting on a related rfc patch instead for now, felt more useful

@corbet Proposing NAKs-per-day as a core community health metric

@vegard @corbet how long did it take you to make this graph? 😳

@Aissen @corbet Not long enough -- I just realized the Y ticks are funky and not well rounded. Take with a grain of salt... (edit: fixed now)

@vegard @corbet Yes, getting healthier all the time

@vegard @corbet Also I already have a workaround

No, sorry this patch is not at
All acceptable. If you
Could, I'd appreciate it if you would
Kindly go away.

@Aissen @vegard @corbet wait that sounds negative, are you nacking the graph??

@vegard @corbet This probably needs some kind of normalization. The number of patches/contributors/maintainers is not constant over time.

@corbet NAK to people -- that's rude, NAK to machines -- that's what it was invented for ;-)

@kmichal @corbet yes! hence it's also perfectly ok for people using machines to pretend it's them

@corbet @brauner while the dma fence and scheduler stuff seems to be the core narrative of that story, it's was a sideshow to the actual problems. We've had 2-3 major refractors and reworks of dma-fence and scheduler since that by people who wanted to fix the underlying problems not just upstream a driver they'd already written and convinced themselves the problem was with the core design. There is even a new rust jobqueue design proposed to solve this properly.

@ljs @corbet

Big Jon has noted that he has managed to get though life without having to ever deploy NACK.

Given his role as 'ed honcho of LWN and a tireless maintainer of some parts of that there Linux, I think his opinion is worth a little more consideration than "disagree profoundly".

Jon is advocating for the diplomatic way and I think you might need to step away from the keyboard occasionally and take a few deep breaths.

There are times to vent and we all do but there are times not to and I think that starts with when you are critiquing someone's work.

@airlied @corbet @brauner email communication is hard. The initial power play made the following emails more difficult to interpret in a good light. Like this one, which I remember as a much stronger threat than it really is on the (then) future hypothetical rust job queue: https://lwn.net/ml/all/43bbd12b-4754-92d1-4000-1ba928d2a8d4@amd.com/

@corbet NAK.