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

[Andrew Sayers <ffmpeg-devel@pileofstuff.org>]

On Sun, Apr 21, 2024 at 01:05:13AM +0200, Michael Niedermayer wrote:
> On Fri, Apr 19, 2024 at 08:00:28PM +0200, Diederick C. Niehorster wrote:
> > On Fri, Apr 19, 2024, 19:35 Zhao Zhili <quinkblack@foxmail.com> wrote:
> > 
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Niklas Haas
> > > > Sent: 2024年4月19日 22:50
> > > > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> > > >
> > > > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer <
> > > michael@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.

It seems like this is splitting into two slightly different questions:

One is "there's a bunch of jobs that could be interesting to someone, but
nobody here wants to do.  How do we attract people who'd want to do them?".
For example, bindings in other languages are only interesting to people who use
those languages, and people here are generally happy with C.

The other is "there's a bunch of jobs nobody will ever want to do, how do we
automate them away?".  For example, it sounds like keeping the website updated
is a boring routine you've found yourself stuck with.

Moving away from the ML has to mean answering the first question with a
trade-off.  For example, I've got several patches outstanding, and I would
*love* an interface that said "assigned: so-and-so" for the ones that just need
a ping, and "unassigned" for the ones I shouldn't waste my limited energy on.
But from your point-of-view, that would mean being chased through your day by a
page of jobs people expect you to get done.

On the other hand, there are many win/win answers to the automation question.
For example, most platforms have some kind of SaaS solution built in (GitHub
Actions, GitLab CI/CD etc.).  It's fairly easy to make these apply every patch
and run fate tests without human intervention, so you can gradually turn review
work from an expert job falling largely on your shoulders to a paint-by-numbers
exercise anyone of moderate skill can do.  That makes it easier for new people
to join the project (because they can do more without help), and frees you up
to work on things that are more fun and add more value.
_______________________________________________
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".