Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes

["Diederick C. Niehorster via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>]

On Fri, Aug 22, 2025 at 2:30 PM Niklas Haas via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> 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.

Absolute and strong +1, this is the better (series of) vote(s) to have.

Thanks Niklas,

All the best,
Dee
_______________________________________________
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".