From: Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] Add tools/merge-all-source-plugins Date: Fri, 16 May 2025 00:25:38 +0800 Message-ID: <tencent_DA2D419A29401D9AA19F89AB164EBA707108@qq.com> (raw) In-Reply-To: <20250515152711.GU29660@pb2> > On May 15, 2025, at 23:27, Michael Niedermayer <michael@niedermayer.cc> wrote: > > Hi Zhao Zhili > > On Thu, May 15, 2025 at 06:58:54PM +0800, Zhao Zhili wrote: >> >> >>> On May 14, 2025, at 18:55, Michael Niedermayer <michael@niedermayer.cc> wrote: >>> >>> Simple script to merge all source plugins. >> >> I think this is confusing. The operation of merging multiple branches can hardly be considered >> a plugin. > > Each branch (well, there is just one ATM) > > represents and contains exactly one plugin or you could also call it feature. > merging that branch integrates that feature / plugin. > > Its a very simple system, it achives many of the goals people have > 1. simple > 2. easy to maintain > 3. it does not allow binary blobs without source > 4. it allows people to develop code under their own rules A plugin is accessories to the main project and cannot work independently on their own. If I understand correctly, this strategy is working with other forks. A fork can merge other forks as many as possible, and call itself the monolithic fork. I want plugin support, mainly due to slow and hard building issues. Current strategy doesn’t help in this case. > > Let me elaborate on 4. > We are not a closed source company, people have the right to work on what > they want to work on. I think 99% of us agree here > > Fact is, this does not work in ffmpeg-devel currently, several people have > had their work rejected for non technical and non legal reasons. > We could remove the most aggressive people, that would reduce this issue > or we could support plugins (source plugins or classical plugins the details > dont matter as long as developers can develop their code on their own terms > and users can use them without censorship by someone) > We also could change the development model to be like linux where this problem > does not exist like this. > > So really, the way i think you should view plugins (and it could be a totally > different implementation of teh concept of a plugin than this here) > Is as a way to keep everyone in one team. > If we cant give people a way to develop code externally and still have > it accessible to users then we have to make it possible to develop > it inside ffmpeg. Or we will loose many new developers who all want to > develop something new and just cannot in this environment. > > That will lead to more conflicts and then the chance of people being kicked > out or leaving will also go up. And if 2 people disagree, the one who wants > to work should stay, and the one who wants to have a say in the work > of the other should leave. Its the obvious way. A person working > vs a person objecting to work. Which way will a project move forward ... > > I want to work, I want everyone else to be able to work, I want everyones > work to be available to the end user. > > thanks > > PS: we can of course rename merge-all-source-plugins if someone has a better > name > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If you think the mosad wants you dead since a long time then you are either > wrong or dead since a long time. > > _______________________________________________ > 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". > _______________________________________________ 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".
next prev parent reply other threads:[~2025-05-15 16:26 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-05-14 10:55 Michael Niedermayer 2025-05-15 10:18 ` Michael Niedermayer 2025-05-15 10:58 ` Zhao Zhili 2025-05-15 15:27 ` Michael Niedermayer 2025-05-15 16:25 ` Zhao Zhili [this message] 2025-05-15 21:54 ` softworkz . 2025-05-15 11:24 ` Rémi Denis-Courmont
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=tencent_DA2D419A29401D9AA19F89AB164EBA707108@qq.com \ --to=quinkblack-at-foxmail.com@ffmpeg.org \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git