[FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kacper Michajlow]

On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo at rothenpieler.org> wrote:
>
> On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
> > On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
> >> It's still an extended test. You cannot push to it, since it's just a
> >> mirror.
> >
> > That's not what written in the announcement, and the fact it is "still
> > a test" has not been communicated on this list, to my knowledge. It's
> > all about as clear as mud...
> >
> > It's possible I am the only one dumb enough to miss that fact, but I suspect
> > (hope) probably not.
>
> It's what the whole vote was about, the vote was not "Let's migrate to
> this", but "Let's put this through a more extended test".
> So I'd say the list was very much informed about that?
>
> >> How do you expect to suddenly switch every last person over from the ML
> >> to a new tool?
> >
> > You do it once, decisively, with no point where it is both dev paths simultaniously.
> > VideoLAN managed it, and countless companies and other projects have managed it with
> > no overlap. Many of which I have experienced first hand. It's one thing to slowly
> > move projects from an org/community over, but having several extant methods of
> > contributing and reviewing the same repo's code is pretty much the #1 thing that
> > is avoided.
>
> Videolan hat the exact same transitional period, where both the ML and
> Gitlab were in use for at least a couple months to half a year.
>
> vlc-devel is still active to this day, even with the very occasional
> stray patch still landing there, just not for patches.
> I expect this to go similar for FFmpeg.
> At some point there will be a more strong PSA sent out that Patches via
> ML will no longer receive the same attention. But so far now is not that
> time.
>
>
> > This isn't really unique to FFmpeg.
> >
> >> There's always going to be a transition period where both are in use,
> >> gradually shifting.
> >
> > ... why? It's not necessary, and is a pretty terrible experience for not
> > much gain except more time for people to argue.
>
> How do you intend to get everybody into one boat to move over all at once?

I don't think moving over is something that requires significant
effort. It just needs clear communication about this.

Also, I don't think the current ML workflow is very sophisticated on
ffmpeg-devel, so there are likely not many tools to migrate to the new
one.

I may be wrong, but ffmpeg development is still within git, so in
terms of producing patches / updating repositories nothing changes.
Except the last mile of sending patches for review and handling this
review. It's a change, but if something is reluctant to do this step
now, I don't think having more time changes this situation.

It's just my personal opinion and it doesn't reflect anyone else in
the community.

- Kacper