[FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org
Kacper Michajlow
kasper93 at gmail.com
Sat Jul 26 23:14:59 EEST 2025
n Sat, 26 Jul 2025 at 21:29, Timo Rothenpieler <timo at rothenpieler.org> wrote:
>
> On 7/26/2025 7:03 PM, Derek Buitenhuis wrote:
> > On 7/22/2025 4:53 AM, Lynne wrote:
> >> ---
> >> src/contact | 11 +++++++++++
> >> src/index | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 63 insertions(+)
> >
> > So I am a bit unclear, is development now Forgejo or ML, or both?
> >
> > Because right now, it seems like both, and that is basically the worst
> > possible outcome. It is very difficult to follow both, and the amount
> > of people reviewing or even looking at patches on either is now significantly
> > splintered/reduced, allowing lower quality code to wade itself in the meantime,
> > IMO.
> >
> > Also, as far as I can tell, the git access list was not really carried over in
> > any way.
> >
> > It all seems a bit chaotic and directionless... or rather, with 0 plan.
>
> It's still an extended test. You cannot push to it, since it's just a
> mirror.
>
> How do you expect to suddenly switch every last person over from the ML
> to a new tool?
> There's always going to be a transition period where both are in use,
> gradually shifting.
> So yes, for now there needs to be eyes on both.
>
> Hopefully pushing to it/hitting the merge button should be possible soon
> (hinges on cooperation with Videolan)
I agree with Derek on this topic, I think it is unreasonable to have
two ways to merge patches into the main repository.
Once the "merge button" is operational, all direct push to the
repository should be restricted and always required to go through PR.
There may still be communication/review overlap between ML/forgejo,
but ultimately it should go through one path of merge/approve.
- Kacper
More information about the ffmpeg-devel
mailing list