On Thu, Apr 16, 2026 at 12:31:58PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > On Wed, Apr 15, 2026 at 04:03:20AM +0200, Michael Niedermayer via > ffmpeg-devel wrote: > > Hi Niklas > > > > On Mon, Apr 13, 2026 at 06:30:30PM +0200, Niklas Haas via ffmpeg-devel > > wrote: > > > > > > > > > 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. > > > > The model is not the limitation here ATM, the problem we have ATM is more > > social and about the interaction between people and Fairy > > not "which LLM is better" > > > > but about technical stuff > > for example i just uploaded all pull requests and issue from forgejo into a > > vector store > > now its just a matter of telling Fairy that she has that data available > > > > If you are curious of the current architecture of this. > > Everything goes in git repositories, > > * ffmpeg as it is, > > * any additional things we want Fairy to be able to access efficiently > > * and now a full dump of all issues and pull requests > > > > Each of these git repositories is uploaded into its own vector store and > > a script keeps them in sync > > > > Fairy then uses these vector stores and can perform semantic search in them > > She also can search the web > > had to rebuild the vector store, because the API refuses too many vector > stores > (rebuild still in progress, currently she is running with 80% of it available) > > so now we will have 1 vector store for ffmpeg git (that one is complete) > and the 2nd will contain multiple git repositories with subtrees (which btw > works > beautifull and simple) > ATM the 2nd git contains forgejo PRs&issues, static documents > intend to add ffmpeg-web and fateserver > > also ive just added this to the prompt > <verification_loop> > Before finalizing: > - Check correctness: does the output satisfy every requirement? > - Check grounding: are factual claims backed by the provided context or tool > outputs? > - Check formatting: does the output match the requested schema or style? > </verification_loop>
i cought her making a off by 1 in one calculation so its now this: @@ -1862,8 +1863,11 @@ Classify the pull request into exactly one of these JSON classes after you have <verification_loop> Before finalizing: - Check correctness: does the output satisfy every requirement? -- Check grounding: are factual claims backed by the provided context or tool outputs? +- Check grounding: is every factual or technical claim supported by the patch, attached files, prior discussion, or tool output? - Check formatting: does the output match the requested schema or style? +- Check derived claims: for every claim that depends on calculation, inference, bounds, integer behavior, bit operations, indexing, or spec interpretation, have you verified it carefully enough to state it as fact? +- Check sanity: do any reported numeric or semantic conclusions contradict known limits, invariants, or the cited specification/context? If yes, re-check before reporting. +- Check uncertainty: if any important point is not well verified, did you mark it as uncertain? </verification_loop> Return JSON only, with this exact shape: [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
