this should be a controversial post lol
Using LLMs to backport approved paches in upstream software into older versions should be significantly easier and more accurate than producing the original patch and reviewing it. In the backport scenario the knowledge that the patch is “good” is already settled. The source around it is in place so the LLM has very tightly bounded context to work with, left with very little freedom to make mistakes. I think LLMs will make LTS releases significantly easier to maintain.
Debian btw.
Greg KH in a recent talk said even the most advanced LLM produces an incorrect result 50% of the time, I would not trust it to perform more reliably than a human even with tight boundaries.
They will do better if you give them a patch to re-apply, so it’s not going to be as bad. But the review effort is probably going to eat up the time saved applying the patch, since you can’t throw a coin on the LLM having done any kind of due diligence on side-effects.
I wonder which way would give a better success rate.
- Write the patch for the latest LTS version and let the LLM forwardport it to master. (But don’t roll out the LTS update until after the rolling distros get the patch?)
- Or write the patch for master and let the LLM backport it to LTS.
Especially if you’re having the LLM port to every active LTS version, maybe option 1 would work since it’s more like a midpoint? Kind of a more neutral zone, fewer commits to conflict in any direction. And that could theoretically prioritize the most recent LTS version as being the most reliable, which is probably what most critical deployments actually need.
