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

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

[Michael Niedermayer via ffmpeg-devel]

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

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.

It is possible that teh community adjusts the exact STF task / work / ...
before its deadline.

I think many people have already thought about the merge vs cherry pick
question. (it came up previously on the ML and in the GA) So maybe we can
just vote on it now over the next 8 days. Or if people want more discussion
first, we can do that too. We will see based on peoples replies.
Maybe use the first day to think and sleep over it or a quick discussion
and then vote in the next 7 days.

If you want to vote, please simply reply with "M" or "C" (and of course any
details, why you think thats the better option, if you want to add details)

Otherwise reply with "D" for "more Discussion" and details about what
you want to say/discuss.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

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

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

[Kieran Kunhya via ffmpeg-devel]

On Thu, 21 Aug 2025, 01:32 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.
>
> It is possible that teh community adjusts the exact STF task / work / ...
> before its deadline.
>
> I think many people have already thought about the merge vs cherry pick
> question. (it came up previously on the ML and in the GA) So maybe we can
> just vote on it now over the next 8 days. Or if people want more discussion
> first, we can do that too. We will see based on peoples replies.
> Maybe use the first day to think and sleep over it or a quick discussion
> and then vote in the next 7 days.
>
> If you want to vote, please simply reply with "M" or "C" (and of course any
> details, why you think thats the better option, if you want to add details)
>
> Otherwise reply with "D" for "more Discussion" and details about what
> you want to say/discuss.
>
> thx
>

D

For the record, Paul had a note saying changes are under GPL. As I
understand you are ignoring legal advice saying this is a valid statement.

Can you confirm the legal advice you were given and that you are ignoring
it?

Kieran

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

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

[Michael Niedermayer via ffmpeg-devel]

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

Hi Kieran

On Thu, Aug 21, 2025 at 06:56:14AM -1000, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> For the record, Paul had a note saying changes are under GPL. As I
> understand you are ignoring legal advice saying this is a valid statement.
> 
> Can you confirm the legal advice you were given and that you are ignoring
> it?

We have hired one of the leading copyright / IP law firms / lawyers

And the shortest summary is that code with LGPL headers can be used under LGPL.
The oppinion of the lawyer (which is much longer and more detailed) was
provided to the General Assembly of FFmpeg.

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates

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

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

[Kieran Kunhya via ffmpeg-devel]

On Thu, 21 Aug 2025, 07:53 Michael Niedermayer via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Hi Kieran
>
> On Thu, Aug 21, 2025 at 06:56:14AM -1000, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > For the record, Paul had a note saying changes are under GPL. As I
> > understand you are ignoring legal advice saying this is a valid
> statement.
> >
> > Can you confirm the legal advice you were given and that you are ignoring
> > it?
>
> We have hired one of the leading copyright / IP law firms / lawyers
>
> And the shortest summary is that code with LGPL headers can be used under
> LGPL.
> The oppinion of the lawyer (which is much longer and more detailed) was
> provided to the General Assembly of FFmpeg.
>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
>

This opinion contradicts the FFlabs lawyer which you said you were going to
use and provided a lengthy justification.

So you basically went around lawyers until you got the answer you want.

Kieran

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

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

[Niklas Haas via ffmpeg-devel]

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

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

[Diederick C. Niehorster via ffmpeg-devel]

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

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

[Michael Niedermayer via ffmpeg-devel]

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

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

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 3181 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.
> 
> 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.

So, lets just make a thought-experiment

1. Mr X forks FFmpeg.
2. Mr X merges Pauls (LGPL) code
3. Mr X adds everything he finds cool or inovative
4. Mr X maintains his fork and stops maintaining anything in FFmpeg
5. Mr X daily merges ffmpeg improvments (and maybe pauls if his code is GPL)
6. Mr X nicely tell FFmpeg that he objects to FFmpeg merging his code ;) ;) ;))))

will ffmpeg comply to this request ?

What if I join these forks, you know each of the forks will take ffmpeg
code and each others work. (within the bounds of each ones licenses)

FFmpeg will not integrate any improvments back ?

Thats how you suggest FFmpeg should be run ?

how could that work ?

thx

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

It is what and why we do it that matters, not just one of them.

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