[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Diederick C. Niehorster]

On Fri, Apr 19, 2024, 19:35 Zhao Zhili <quinkblack at foxmail.com> wrote:

>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Niklas Haas
> > Sent: 2024年4月19日 22:50
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> >
> > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer <
> michael at niedermayer.cc> wrote:
> > > A plugin system moves this patch-management to people who actually
> > > care, that is the authors of the codecs and (de)muxers.
> >
> > A plugin system will only solve this insomuch as plugin authors will
> > just host their plugin code on GitHub instead of bothering with the
> > mailing list.
> >
> > I think it runs a good risk of basically killing the project.
>
> VLC is plugin based, gstreamer is plugin based too (which went toooo far
> 😝),
> I don't think plugin is that dangerous.
>
> Firstly, we can enable plugin interface only with enable-gpl.
>
> Secondly, we can have a less stable plugin interface than public API, for
> our
> development convenience, and encourage plugin authors to contribute to
> upstream.
>
> >
> > > Our productivity as is, is not good, many patches are ignored.
> > > The people caring about these patches are their Authors and yet they
> > > are powerless as they must sometimes wait many months for reviews
> >
> > So, rather than all of the above, what I think we should do is contract
> > somebody to set up, manage, host and maintain a GitLab instance for us.
> >
> > This would probably be the single most cost effective boost to both
> > community growth and innovation I can think of, as it will remove
> > several of the major grievances and barriers to entry with the
> > ML+pingspam model.
>
> +1.
>
> I can't remember how many patches I have ping. It's really frustration.
> I ask for permission to commit mostly due to this.
>
> Now I can keep track of my own patches, but it's still not easy to filter
> out
> patches I'm interested to review (I can blame the email client, but blame
> it
> doesn't help). I'm sure I can review more patches with a new workflow.
>

If i recall correctly, there was a conversation not too long ago about what
to do with all the SPI money. This seems to be a perfect use for it.
1. Set up and manage a gitlab instance
2. Move tickets from trac to there (possibly)
3. Move fate running to there

Etc

>