On Sun, Apr 12, 2026, at 6:41 PM, Michael Niedermayer via ffmpeg-devel wrote: > Hi everyone > > Last easterbunny brought eggs and in one egg there was a life fairy. > She said her name is forgejo fairy and she wants to help the project > and community. > > She is still quite young so please be gentle with her, ATM what she can do is > * scan pull requests for ones that are stale. More precissely > + No activity for 7 days and > + open and > + not WIP and > + CI passes and > + mergable = no conflicts and > + no open change requests and > + activity since the last fairy reaction or no previous and > > * she can read the patches, files patched and around 5000 files from > FFmpeg git HEAD > as well as all past comments in the PR > * she will try to review the changes and write a clean and concise > comment > also considering past comments so as no to add redudant information > * if EVERYTHING lines up she will approve the PR > this will not on its own trigger any merge. Only if some human > developer > clicks the merge/rebase button or has previously set the PR to auto > merge > will that trigger a merge (this affects ATM at maximum 6 PRs) > * you can add her to the reviewer of a PR and that will decrease the > "No activity" time to 1 day for that PR
I think having an LLM automatically scan PRs for bugs, typos, undefined behavior etc is beneficial. I personally run every bigger series through Claude Code, even those made by others, and it is very good at finding bugs, especially ones missable by humans. I actually think that automatic bug analysis can be done even in addition to human review. However, I think the following criteria are needed to adopt this: 1. The prompt should be published in the git repository, so that we can see and propose changes to it. 2. It should only run / auto-approve PRa made by people with commit rights. 3. The model used should also be documented publicly, and, per my recommendation, should be Claude Opus 4.6. As for the prompt used, it should be some variation of “Scan this PR for bugs, mistakes, typos, undefined behavior, regressions, unintended side effects and other issues.” I find that this specific prompt works very well for me, and prevents noise in the output. In particular, a generic “review this PR” is too open-ended and results in noise. Based on the results in your links, I suspect that either the prompt or the model could be changed for something better. > > Initially, i will set the "No activity time" to 56 days so she will only > process > teh very stalest PRs and then slowly decrease it > Also it will be run by hand not by cron job first and manually supervised. > (that means i should be able to stop anything outrageous but i certainly > will not recognize incorrect reviews) > > My expectation is that >50% of the reviews will be usefull > > As she grows she will gain more abilities > > How to opt out? Get a human review before the 7-56 days > > Examples: > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20005#issuecomment-36271 > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20059#issuecomment-36273 > > Thx > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many that live deserve death. And some that die deserve life. Can you give > it to them? Then do not be too eager to deal out death in judgement. For > even the very wise cannot see all ends. -- Gandalf > > _______________________________________________ > ffmpeg-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > Attachments: > * signature.asc _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
