On Fri, Apr 19, 2024 at 08:00:28PM +0200, Diederick C. Niehorster wrote: > On Fri, Apr 19, 2024, 19:35 Zhao Zhili <quinkbl...@foxmail.com> wrote: > > > > > > -----Original Message----- > > > From: ffmpeg-devel <ffmpeg-devel-boun...@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 < > > mich...@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
signature.asc
Description: PGP signature
_______________________________________________ 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".