alt Hacker NewsKdenlive has some unfortunate performance regression when working with larger projects with many clips.
I managed to track down a few of them while evaluating Claude Code a while back (mostly certain actions doing O(n) scans over all clips every mouse event needing debouncing), and got it mostly back down to tolerable levels again, but have been holding onto them because unsolicited drive by AI PRs are very annoying from a code project maintenance perspective, as the changes are almost certainly poorly factored.
Was half considering creating a Kdenvibe fork, but that would also be in bad taste. So right now I don't know what to do with the diff.
Replies
Creating the PR, doing the explanation you just did, and closing it yourself might be a good option. Then at least your code lives somewhere that someone else can reuse if desired. Ideally combined with a linked issue that you do keep open.
You can write a bug report for each problem and attach a patch with the corresponding hack. Best thing you can do short of providing clean fixes.
You should be running your own fork before making pull requests. You don’t have to get other people to use it, you just need to get in the habit of rebasing regularly and cutting releases for yourself. Someday I hope maintainers get better visibility into downstream improvements without the politics of pull requests.
Id say ask AI to ‘describe the problem and solution from a high level. avoid code excerpts if possible.’ Submit as a bug report and mention you have an AI solution for reference if desired.
I'd open a Draft PR and an Issue to explain the problems you encountered and how you've solved them for your own use cases... then leave it up to them to learn from it or close it.
I get annoyed with "drive-by PRs" only when they lack context or are clearly just a way to get some commits into a project (typos and so on), but any findings that can improve my code or its performance is welcome, in my projects at least.