On Sun, Mar 22, 2026, at 4:23 PM, Michael Niedermayer via ffmpeg-devel wrote: > 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.
And do you agree that having a checkasm repo on FFmpeg forgejo would alleviate those concerns? > > 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 > > _______________________________________________ > 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]
