michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 8.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<andrewrk>
I think you should simply disable forks and suggest for contributors to use the agit workflow
<andrewrk>
that's what we would do anyway. but I think we're going to stick with codeberg for a little while longer
<BtbN>
specially if you want to have a lengthy description
<andrewrk>
it's just `git push origin HEAD:refs/for/main` and then you can go edit the PR in the web ui
<BtbN>
At which point notifcation mails with incomplete title and body have already gone out, and will forever be what I see in my mail history...
<andrewrk>
if we count steps it's 1 step (agit) vs 3 steps (forking)
<andrewrk>
it uses the first commit for title and body by default
<BtbN>
Looking at my mail history, it uses the branch name
<andrewrk>
I stand corrected
<BtbN>
And ironically, agit also server side makes the storage problem worse :D
<BtbN>
Cause each agit pr is a fork
<andrewrk>
anyway I don't have any point to prove, I'm just trying to collect information
<BtbN>
To avoid commit-smuggling
<BtbN>
It's a shallow one I think though, so not full storage use
<andrewrk>
I mean if it reaps them on closure that should be fine
<BtbN>
I hope it does, I never checked
<BtbN>
though realistically, if we enforced agit, we'd by now have more of those than actual forks
<BtbN>
open ones
<andrewrk>
interesting point
<andrewrk>
it really should only need to store the files edited, not anything else from the main repo...
<BtbN>
yeah, it's not a full on fork like a forked repo is
<BtbN>
but it is not stored inside of the repo
<andrewrk>
security schmecurity
<BtbN>
Well, it was decided, by vote, that it's a security concern if a fork can inject objects into your repo
<BtbN>
So that's what's being acted on
<BtbN>
hm, it also seems like only a handful of forks are responsible for the vast majority of storage use
<BtbN>
Nothing suspicious in them at first glance though. Just active, so very diverged pack files
<andrewrk>
handful of codecs are responsible for the vast majority of videos encoded
<andrewrk>
pareto principle strikes again
<BtbN>
It's also not like we're talking about unfathomable storage sizes here
<andrewrk>
how much, if you don't mind sharing?
<BtbN>
right now it's around 30GB deduplicated via hardlinks
<BtbN>
And would be ~120GB if the hardlinks suddenly turned into independent files
<andrewrk>
and that's with about 405 forks?
<BtbN>
393 ffmpeg.git directories at least
<BtbN>
It's more that the current server has 160GB of disk space. And upgrading it has gotten prohibitively expensive
<BtbN>
So I'd kinda like to keep fitting into that
<BtbN>
I could move them out into a block storage volume. But those are not part of the automatic snapshots of the whole server, so using it would instantly neccesitate a much more involved recovery strategy
<fjlogger>
[FFmpeg/FFmpeg] Issue #23451 opened: MTV demuxer: video_fps zero due to integer truncation causes invalid timebase (incomplete fix for #755) (https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23451) by 51511