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

[Derek Buitenhuis <derek.buitenhuis@gmail.com>]

On 7/26/2025 9:14 PM, Timo Rothenpieler wrote:
> 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?

I'd say this announcement should be amended to reflect this then, because it
does not read at all like testing, but the new sole way to contribute.

(I did indeed miss the single sentence that missed testing at the beginning there, for the
steps like "* announce code.ffmpeg.org publically so people can start submittin and reviewing
on it as an alternative to the ML".)

>>> 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.

I remember a period where patches that got sent to the ML got told to
use the new method, but not a period where it was treated simultaniously
as an equal and continuing method to contribute. Very possible I am
misremembering, but that's that I recall.

> vlc-devel is still active to this day, even with the very occasional 
> stray patch still landing there, just not for patches.

Unrelated, really. Nobody proposed killing this list for discussion purposes.

> 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.

As above, suggest rewording the ffmpeg.org change then to better reflect this.

> How do you intend to get everybody into one boat to move over all at once?

Update the contrib docs, and start replying to ML patches (either automated or
not) with instructions on using Forgejo. After a short period, you disable the
old method and/or repo, and only allow the new one (not an extended period).

During the period above, do not treat ML contributions as business as usual.

> VLC has a central governing body who is able to make such decisions and 
> force the issue if need be.

Does the GA not cover this? I did notice the vote was very specifically not
put to GA vote, meaning there can be further endless arguing and refusal to
move.

> FFmpeg does not, so I don't see who would be able to make such a call, 
> and specially then also have everyone follow it.

GA. Vote on it, implement it. That's the end of it.

Either that, or ditch the GA, as it is literally pointless, and acknowledhe
FFmpeg is Michael's project.

- Derek
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".