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

[Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3336 bytes --]

Hi Niklas

On Fri, Aug 22, 2025 at 02:29:56PM +0200, Niklas Haas via ffmpeg-devel 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.

This here is a simple (and transparent) vote
Using the mailing list allows people also to discuss and explain their
reasonings (like you did here)

I do think there is value in hearing the reasonings of people and not
just seeing a number of how many are in favor vs against.


[...]

> > 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.

That was always possible, people can and could always discuss and object to
proposals.

What we submit to STF should be proposals that have a broad consensus not
51% behind them


> 
> 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 infrastructure will tell you what the majority voted for.
Not why
Nor will it lead to a consensus if theres none before

but open discussion can lead to consensus

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".