On Tue, 29 Sept 2026 at 17:02, Antheas Kapenekakis <[email protected]> wrote: > > 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.
I think I thought of a solution that does have precedent. The kernel forces you to have a local version file, otherwise it adds a .test wart. At least on Fedora. So there is precedent for requiring the user to create a file to disable some default behavior. Similarly, you swap this series into a two parter. The first patch gitignores agents.md. The second patch adds a phony rule to the makefile that symlinks agents.md to the coding assistants rst or similar if it does not exist. People that do not want that, like me, touch that file. Not to the current readme, please. Be reasonable. Yes the coding assistants rst file is not ideal either but that can be fixed later. If it is done like this, I do not have a problem with it. To prevent regressions down the line if a template agents.md file should exist but an existing agents.md symlink was provided, you can symlink AGENTS.md to Documentation/process/AGENTS.md which is itself a symlink to ./coding-assistants.rst and committed as part of that patch. Best, Antheas > Best, > Antheas > > > -- > > Thanks, > > Sasha > >
