From: Kacper Michajlow <kasper93@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org
Date: Sat, 26 Jul 2025 23:07:48 +0200
Message-ID: <CABPLASQkeB-D=NmDEmvJnGZTgtymcE7p_RX0b6=_SVPpVmmJXw@mail.gmail.com> (raw)
In-Reply-To: <9ba27e8b-f890-4b34-a2a0-6245bb050145@rothenpieler.org>
On Sat, 26 Jul 2025 at 22:42, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>
> 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?
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
_______________________________________________
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".
next prev parent reply other threads:[~2025-07-26 21:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 3:53 Lynne
2025-07-22 8:44 ` Kacper Michajlow
2025-07-22 9:15 ` Jacob Lifshay
2025-07-25 3:40 ` compn
2025-07-25 3:58 ` Jacob Lifshay
2025-07-25 4:36 ` compn
2025-07-25 11:41 ` Nicolas George
2025-07-25 14:20 ` Kieran Kunhya via ffmpeg-devel
2025-07-23 4:05 ` Lynne
2025-07-22 15:01 ` Leo Izen
2025-07-23 4:01 ` Lynne
2025-07-22 23:04 ` Michael Niedermayer
2025-07-23 4:01 ` Lynne
2025-07-23 9:16 ` Michael Niedermayer
2025-07-23 9:39 ` Kieran Kunhya via ffmpeg-devel
2025-07-23 9:59 ` Michael Niedermayer
2025-07-23 10:02 ` Kieran Kunhya via ffmpeg-devel
2025-07-23 11:48 ` Nicolas George
2025-07-25 4:05 ` compn
2025-07-26 14:57 ` Michael Niedermayer
2025-07-23 9:38 ` Michael Niedermayer
2025-07-23 11:49 ` Nicolas George
2025-07-26 17:03 ` Derek Buitenhuis
2025-07-26 19:29 ` Timo Rothenpieler
2025-07-26 20:01 ` Derek Buitenhuis
2025-07-26 20:14 ` Timo Rothenpieler
2025-07-26 20:24 ` Kacper Michajlow
2025-07-26 20:29 ` Derek Buitenhuis
2025-07-26 20:41 ` Timo Rothenpieler
2025-07-26 20:45 ` Derek Buitenhuis
2025-07-26 21:07 ` Kacper Michajlow [this message]
2025-07-26 21:18 ` Timo Rothenpieler
2025-07-26 22:44 ` Michael Niedermayer
2025-07-26 22:57 ` Timo Rothenpieler
2025-07-26 22:48 ` Michael Niedermayer
2025-07-26 20:28 ` Derek Buitenhuis
2025-07-26 20:14 ` Kacper Michajlow
2025-07-26 20:23 ` Timo Rothenpieler
2025-07-26 20:29 ` Kacper Michajlow
2025-07-26 20:33 ` Derek Buitenhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABPLASQkeB-D=NmDEmvJnGZTgtymcE7p_RX0b6=_SVPpVmmJXw@mail.gmail.com' \
--to=kasper93@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git