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

[Michael Niedermayer]

On Fri, Apr 19, 2024 at 08:00:28PM +0200, Diederick C. Niehorster wrote:
> 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

I think we first need to understand what exact problem there is with the
ML/Patchwork workflow. Write this down. See if we all agree on that

Look at what workflow* people use
Look at what alternatives to ML/Patchwork there are
I think others than gitlab where suggested like gittea and forgejo

And then carefully evaluate each for cost vs benefit.

If we agree on one then its probably best to setup a small test environment
and have the whole team try to use that before we consider a switch


> 2. Move tickets from trac to there (possibly)

why ?


> 3. Move fate running to there

why ?


workflow*
    For example, i go through patches on the ML with mutt and i have one key
    to apply a patch and another to open an editor and write a reply. Also i have
    my muttrc setup so it colorizes diffs nicely so patches are easy to review
    I do test close to every patch posted on ffmpeg-devel, so being able
    to quickly apply patches matters. If i had to use a GUI based browser
    and click around with the mouse it would probably mean an end for me
    testing all patches, simply as it would be too inconvenient and slow.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240421/1205fb19/attachment.sig>