Hi Martin On Sat, Mar 21, 2026 at 11:15:06PM +0200, Martin Storsjö via ffmpeg-devel wrote: > On Sat, 21 Mar 2026, Michael Niedermayer via ffmpeg-devel wrote: > > > > Nothing requires a dependency on external infrastructure. > > > > The imported tree clearly points users and contributors to external > > infrastructure: > > > > +tests/checkasm/ext/docs/getting-started.md:url = > > https://code.videolan.org/videolan/checkasm.git > > +tests/checkasm/ext/docs/getting-started.md:git submodule add -b release > > https://code.videolan.org/videolan/checkasm subprojects/checkasm > > +tests/checkasm/ext/docs/introduction.md:- [**GitLab > > Repository**](https://code.videolan.org/videolan/checkasm) > > +tests/checkasm/ext/docs/introduction.md:- [**Issue > > Tracker**](https://code.videolan.org/videolan/checkasm/issues) > > +tests/checkasm/ext/docs/introduction.md:- [VideoLAN > > Homepage](https://www.videolan.org/) > > +tests/checkasm/ext/src/html_data/body.html: This report was created > > using the <a id="checkasm-version" > > href="https://code.videolan.org/videolan/checkasm";>checkasm</a> > > > > So even if you do not consider that a hard technical dependency, it is > > still an integration centered around external infrastructure and external > > project entry points. > > So if you are bothered by those files,
I am not concerned about those files merely existing. I am concerned about FFmpeg importing code in a form that points users and developers away from FFmpeg infrastructure. Whether this is done as a git subtree, a linked libcheckasm library, or some other mechanism is a secondary technical question. My main concern is that checkasm, if used by FFmpeg as part of our testing infrastructure, should be hosted and maintained in a way that FFmpeg can control on code.ffmpeg.org. Checkasm is important enough that we need to be able to fix bugs, address security issues, and add features without depending on an externally managed project and release cycle. That is also why I said that if there is an upstream outside FFmpeg, then it is important that merging changes in both directions is not only theoretically possible, but actually practical and beneficial to both sides. > then we could import the code in the > form of a code drop, removing all these files, and just keeping the source > files (the src/ and include/ subdirectories). With a script for updating > that from upstream, it should be straightforward to use. A script can certainly be useful, but that depends on what exactly it does. For example, if it loses local changes, makes merges unnecessarily painful, or creates a messy and unclear git history, then that would not be a good solution. If it provides a clean and maintainable update path, then that is a different matter. [...] > > * a clear and reviewed attribution/relicensing story > > For what it's worth, I have reviewed the whole history of this split out > repo, from the start from the dav1d checkasm import, through all the > refactoring and libraryfication of it. That is useful to know. If you are saying that you have reviewed the authorship, copyright, and relicensing history and believe it is correct, then that addresses part of my concern. I still think that, for something of this size, it would be good if that attribution and relicensing story were documented clearly enough that others do not have to rely only on private review of the full history. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
