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

[Kacper Michajlow]

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.

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.

- Kacper