From: Niklas Haas via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> To: Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>, FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Cc: Niklas Haas <ffmpeg@haasn.xyz>, Michael Niedermayer <michael@niedermayer.cc> Subject: Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes Date: Fri, 22 Aug 2025 14:29:56 +0200 Message-ID: <20250822142956.GB11733@haasn.xyz> (raw) In-Reply-To: <20250821113202.GH29660@pb2> On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > Hi > > Should we use a Merge or Cherry picks for integrating Pauls work ? > > Following are 2 plans, as we execute either we may run into issues > and of course adapt them as needed. (or even switch) > > Option M: > This would be a merge of pauls last revission before files where > switched to GPL and the command line tool to AGPL > > It would include all changes (except what is intentionally skiped) > (This will look similar to how almpeg looks now) > > Fate tests would be added after the merge where sample media is > publically available on our server. > Reviews of Individual modules can be done after the merge where > people want to do that. > > Option C: > Individual Modules (Codecs, Filters, Demuxers) would be submitted > as patch(sets) > > This would include only the picked changes. Changes noone picks and > posts would be missing. > > Each would go through the review process (some likely with "apply > after timeout"). And during that review fate tests would be added > where public samples are on our server. > > M would likely integrate more changes, C less changes. C may be more work. > > We currently have a point on the wiki for STF 2025 that would fund each > integrated module with 900€. > That way, whoever adds fate tests, makes changes the community wants in > a review, fixes bugs found by tests or review, could be funded. D Since you tagged the GA on this, I am going to go ahead and request that a formal GA vote, which I assume will be conducted before any action, must have the option to vote that we respect Paul's request (and arguably, his legal right) to not merge his work into FFmpeg. Even if you personally think the risk of Paul litigating FFmpeg in response is neglible, and are willing to shoulder the potential costs of a legal battle on your own shoulders, I do not think it sets a good precedent and will be potentially damaging to the FFmpeg project's public image. > It is possible that teh community adjusts the exact STF task / work / ... > before its deadline. I think that SPI/STF projects should also be voted on by the GA before being approved for inclusion in the contract proposal. We already have the infrastructure for this in place, and I am sure that the majority of the GA members would rather spend 5 minutes of their time reviewing each project proposal rather than having it handled in an ad-hoc manner. The last STF round already received a number of criticisms about lack of transparency, so I think this would be a step in the right direction. _______________________________________________ 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-08-22 12:30 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-08-21 11:32 Michael Niedermayer via ffmpeg-devel 2025-08-21 16:56 ` Kieran Kunhya via ffmpeg-devel 2025-08-21 17:53 ` Michael Niedermayer via ffmpeg-devel 2025-08-21 17:58 ` Kieran Kunhya via ffmpeg-devel 2025-08-22 12:29 ` Niklas Haas via ffmpeg-devel [this message] 2025-08-22 12:45 ` Diederick C. Niehorster via ffmpeg-devel 2025-08-22 12:59 ` Michael Niedermayer via ffmpeg-devel 2025-08-22 13:45 ` Michael Niedermayer via ffmpeg-devel
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=20250822142956.GB11733@haasn.xyz \ --to=ffmpeg-devel@ffmpeg.org \ --cc=ffmpeg@haasn.xyz \ --cc=michael@niedermayer.cc \ /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