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

[Timo Rothenpieler <timo@rothenpieler.org>]

On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
> On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@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?

> - Kacper


Here's an idea I had to make the transition a bit more rapid:

  - Retire git.videolan.org, make it a pure mirror nobody can push to 
(except the mirror script).
  - Make source.ffmpeg.org point to git.ffmpeg.org instead. This will 
cause host key mismatches for everyone, but if it's clearly announced, 
with the new host keys in the announcement, it should not be too horrible.
  - Set up git.ffmpeg.org to forward all pushes to code.ffmpeg.org, 
without them ever hitting the local repo
  - code.ffmpeg.org then becomes the main repo, so the merge button can 
be enabled without causing a split-brain situation.
  - The same mirror scripts will then keep git.ffmpeg.org up to date for 
pulling.

This allows people to keep their current workflow without being forced 
to sign up on Forgejo, while allowing Forgejo to be fully operational.
Worst that might happen is for people who push directly to g.v.o, who 
will have to reconfigure their remote.

In theory the same kind of forwarding is possible directly from g.v.o, 
but it requires a custom script and then manual maintenance of keys 
allowed to push (or a patched gitolite), so that's unlikely to happen 
and will be annoying to maintain.
_______________________________________________
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".