On Tue, 29 Sept 2026 at 16:02, Sasha Levin <[email protected]> wrote: > > On Sun, Sep 27, 2026 at 05:24:46PM +0200, Antheas Kapenekakis wrote: > >On Sun, 27 Sept 2026 at 16:06, Sasha Levin <[email protected]> wrote: > >> If someone adds their sign-off without understanding what it certifies, > >> that's on them. We can't have agents add it for them just because some > >> people would ignore its meaning anyway. > > > >I didn't say we should make the agent add it. I said if someone wants > >to do it it is up to them. Not you, not the mainline kernel config, > >not this patch. And disabling it does nothing because the user does > >not understand what a sign off is anyway and will add it later or > >submit without it. In which case you get broken patches anyway and you > >solved nothing. > > Again, that's on the user. Your argument is saying that we should just drop > this whole DCO nonsense because no one understands it anyway. > > We can't stop enforcing things just because users don't bother reading the > docs.
If it is up to the user, then this patch is not needed. If it is not and the kernel should make LLMs prompt the user to do a better job with DCO, then this patch does not provide a solution. I never said anything about enforcement and this patch is not about enforcement anyway. > Nothing is stopping you from changing this behavior to your liking either, but > at that point it makes you a downstream consumer on the kernel, so you get to > carry that delta. I am aware. The issue of switching to a mainline tree for upstreaming remains. Your symlink would come back. What is the solution for this? > >> If you think a hand-written AGENTS.md would do better, feel free to > >> write one and propose it. For now, this one seems to be working just > >> fine. > > > >No, I am fine with one not existing and it would be my preference > >actually. Ideally it would be added to .gitignore as well. > > > >That just does not address your need of steering novel contributor > >plus LLM, which I tried to help with. But if you do not want to put > >more effort than a symlink then not breaking our workflows is more > >important so this patch should not merge. > > All I care about is having all these "agents" follow the rules and guidelines > that the kernel community set around LLM contributions. I'm not trying to > improve the quality or make it more efficient. This patch is purely about > having the majority of LLM agents follow our rules out of the box. > > If you want to spend a few months trying to massage an AGENTS.md to the liking > of your LLMs-of-choice, then go at it. In doing so, you should consider the environmental impact and cost this symlink will have by providing an unoptimized indexing blob to LLMs which will also prompt additional tool calls. Then, the headaches it will cause kernel developers that do know what a DCO is or want to have a custom agents.md file, specifically the git errors that will be caused when upstreaming as the agents.md file will be dirty. I get what you are trying to do. But you need to address the underlying issues here. You can't just handwave them. Contributing to the kernel has never been "out of the box" and the kernel is not set up for that in multiple ways. If you want there to be an exception for LLMs such that they do a decent job at it by default, if anything to prevent a flood of patches with obvious defects, then I would agree with that goal. But in that case, you need to make sure that people that know how to use LLMs and know what a DCO is are not negatively affected. No, it is not ok to append 2k tokens to everyone's context or 2-3 more toolcalls for every agent thread. It is also not ok to have to do gymnastics to remove the symlink when switching to a clean tree for upstreaming. And even for novel contributors this is not ok. I am blessed to have the disposable income to pay 100$ per month to access LLM services. Even so, I have to make every % of usage count. Novel contributors are not. They are typically using free services, 10-20$ plans, or local models. Those models are disproportionately affected by a poor agents.md file and so is their usage. I would like to see these issues resolved prior to the kernel providing an agents.md file or similar (if it should do so) and this is a very fair ask. I do not believe I am unreasonable. Also, the above is a prerequisite for adding a default agents.md file and does not pertain to its contents. That is a separate discussion altogether. Best, Antheas > -- > Thanks, > Sasha >
