On Sat, 26 Jul 2025 at 22:42, Timo Rothenpieler <t...@rothenpieler.org> wrote: > > On 7/26/2025 10:24 PM, Kacper Michajlow wrote: > > On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <t...@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-requ...@ffmpeg.org with subject "unsubscribe".