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

[Timo Rothenpieler]

On 7/26/2025 11:07 PM, Kacper Michajlow wrote:
> On Sat, 26 Jul 2025 at 22:42, Timo Rothenpieler <timo at rothenpieler.org> wrote:
>>
>> On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
>>> 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.
>>
>> The problem is the lack of any kind of governing body who can
>> communicate it in the first place.
>>
>>> 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.
>>
>> You'd be surprised about the sophisticated tooling a lot of people have
>> built around patch wrangling via a mailing-list.
>>
>> A lot of people will need to learn an entire new workflow, and I can
>> absolutely understand that being forced to do so from one day to the
>> next is very disruptive and off putting.
>>
>>> 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.
>>
>> Again, many people have literal decades of experience and tooling set up
>> to deal with this exact workflow.
>> Some kind of transitional period is absolutely warranted.
>>
>>> It's just my personal opinion and it doesn't reflect anyone else in
>>> the community.
>>
>> I'm completely with you that we desperately need to move forward.
>> But there just are a lot of people who've been with the project for a
>> long time who are not comfortable with it or outright reject it.
>> Do we really want to just leave them behind, and not even give them a
>> chance to learn new tools?
> 
> No, of course not. I didn't mean it like that. Though sooner or later
> the migration will happen, if I understand the current situation
> correctly.

My point is that there is nobody/nothing that can make a definite call 
"migrate now".
I guess the group of server admins kinda has that power, in that we 
could just make it so, and only allow PRs and no direct pushes anymore.
But that would definitely not go down well and I don't think anyone will 
go that route.

> I guess it would be easier if Forgejo would allow creating PRs by
> email. Though as I understand this is not supported and would have
> challenges of its own anyway.
While it's not possible to create them via E-Mail, it's absolutely 
possible to create them via CLI with the tea tool.

https://gitea.com/gitea/tea

So except for initial signup, you can interact with Forgejo entirely 
from CLI and E-Mail notifications if you so desire.