Hi Philippe, thanks for the feedback.
The file is taken from the upstream 6.4 branch and, as I wrote, it contains only two fixes, one of which is the problem affecting you. Anyway, if you prefer not to try it, that's fine: from the test I did it looks like the solution, and it is already in Debian testing/unstable.
About the llm analyses: I had a look. They are generic remarks on the whole file, not on the problem you reported, and they mostly concern code that has been there for years (as one of them notes, much of it comes from GNOME Shell, from which this file derives). None of them comes with a real case where something actually goes wrong. Verifying each point properly would take hours, for me and for the upstream developers, for probably little benefit, so I won't follow them up unless one of them shows up as a real problem.
Allow me a more general word of caution, which is not meant as a criticism of you. Language models (LLMs) are called "artificial intelligence", and many people without experience think they really are intelligent, without any idea of how they basically work. They can be very useful, but they can also do damage.
In the last months I have been using them a lot, and they have helped me a lot. But it took me dozens of hours to learn how to use them well, to set up their basic instructions and memory, and to prepare test environments for the first automatic checks. Even with all that, I always have to guide them, correct them and check what they produce. They have saved me time in triaging dozens of bugs and in contributing some fixes upstream, but I still had to spend a lot of time by hand: I don't know exactly, but surely well over a hundred hours by now on Cinnamon bug triage and contributions in the last months.
Unfortunately many inexperienced users use LLMs to produce piles of bug reports and contributions without the necessary research and checks, often with poor or wrong results that only waste the maintainers' time. Just yesterday I spent time reviewing some contributions that, I suppose, were made by someone inexperienced who quickly ran an LLM on issues and bugs left open. Many of the problems that LLMs find are not very relevant, or have never been reproduced in practice. And some changes that seem to fix a small problem in a narrow piece of code do serious damage in the larger, real context. One of the changes I looked at yesterday gave me exactly that impression: it looked correct in the few lines it touched, it probably didn't come from a real problem anyone had seen, and in the bigger picture it would have broken something important.
This is why I prefer not to invest too much time in fixing long lists of small problems found by quick LLM scans: the risk is wasting a lot of my time and of the upstream maintainers' time for a small advantage, sometimes with more risks than benefits. Even while I work on a specific problem, the LLMs point out other issues they notice along the way: I ignore most of them and consider only a few, after evaluating them.
Best regards, Fabio
OpenPGP_signature.asc
Description: OpenPGP digital signature
