* [FFmpeg-devel] STF SoWs
@ 2024-02-06 2:06 Michael Niedermayer
2024-02-06 14:18 ` Ronald S. Bultje
2024-02-06 14:57 ` Vittorio Giovara
0 siblings, 2 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 2:06 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Jonatas L. Nogueira
[-- Attachment #1.1: Type: text/plain, Size: 2805 bytes --]
Hi all
As Jonatan reminded the ML we need to provide SoWs if we want to
participate in STF-SPI
We need one for each project (they do not need to list a person ATM)
but obviously we do need someone who will do the work
I do belive they do need to list the money amount.
Thanks go to Pierre for helping me write template/example.
(converted from google docs and with some last minute edits)
@Jonatan, is this below what SPI needs for each project ?
STF SOW template
1. One line summary of the proposed work
Classify and fix outstanding issues identified by Coverity
2. Description of the work
Coverity is a static code analysis system that is used to analyze FFmpeg code to find bugs with an emphasis on quality and security issues. There are currently 677 outstanding issues identified by Coverity (https://scan.coverity.com/projects/ffmpeg?tab=overview). Some of these issues are false positives while others could open the door to security vulnerabilities.
The objective of this work is to identify the Coverity issues that are not false positives, and fix as many as possible.
3. Milestones
1. Milestone 1
1. Description
Review all outstanding Coverity issues and, for each one, determine whether it is a false positive.
2. Deliverables
List of both false positive and potentially real issues posted to the FFMPEG dev mailing list.
3. Compensation
XXXXX euros
2. Milestone 2
1. Description
Fix 50% of the outstanding real issues
2. Deliverables
Patches submitted for review to the FFMPEG dev mailing list.
3. Compensation
XXXXX euros
3. Milestone 3
1. Description
Fix 45% of the remaining outstanding real issues. The total number of issues addressed by Milestones 2 and 3 do not total 100% to account for issues that are not practical to fix within the scope of this SOW and are deferred to future work.
2. Deliverables
Patches submitted for review to the FFMPEG dev mailing list.
3. Compensation
XXXXX euros
4. Developer(s)
Michael Niedermayer <michael-ffwork@niedermayer.cc>
I work in Austria, and have been an active contributor to FFmpeg since 2001 – 22308 commits so far. My work on FFMPEG is regularly supported by third parties and I am one of the founders of fflabs. I am also familiar with Coverity: I have fixed 563 issues out of 896 Coverity issues fixed in the past (according to gitlog *1). I fixed over 2000 issues found by ossfuzz.
(*)
git shortlog -s -n -i --no-merges --first-parent --grep 'fix.*\(CID\|coverity\)'
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 2:06 [FFmpeg-devel] STF SoWs Michael Niedermayer
@ 2024-02-06 14:18 ` Ronald S. Bultje
2024-02-06 15:04 ` Vittorio Giovara
` (2 more replies)
2024-02-06 14:57 ` Vittorio Giovara
1 sibling, 3 replies; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-06 14:18 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Jonatas L. Nogueira
Hi,
On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> 2. Deliverables
> Patches submitted for review to the FFMPEG dev mailing list.
>
I think the goal is to get patches merged, not submitted.
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 2:06 [FFmpeg-devel] STF SoWs Michael Niedermayer
2024-02-06 14:18 ` Ronald S. Bultje
@ 2024-02-06 14:57 ` Vittorio Giovara
2024-02-06 15:25 ` Michael Niedermayer
1 sibling, 1 reply; 32+ messages in thread
From: Vittorio Giovara @ 2024-02-06 14:57 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Jonatas L. Nogueira
On Tue, Feb 6, 2024 at 3:06 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> Hi all
>
> As Jonatan reminded the ML we need to provide SoWs if we want to
> participate in STF-SPI
>
> We need one for each project (they do not need to list a person ATM)
> but obviously we do need someone who will do the work
>
> I do belive they do need to list the money amount.
> Thanks go to Pierre for helping me write template/example.
> (converted from google docs and with some last minute edits)
>
> @Jonatan, is this below what SPI needs for each project ?
>
Correct me if I'm wrong but we still need the answer on "merge forks".
Which ones, where, and why -- ie what if the community doesn't want or need
any particular one?
--
Vittorio
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 14:18 ` Ronald S. Bultje
@ 2024-02-06 15:04 ` Vittorio Giovara
2024-02-06 15:14 ` Michael Niedermayer
2024-02-06 15:59 ` Niklas Haas
2 siblings, 0 replies; 32+ messages in thread
From: Vittorio Giovara @ 2024-02-06 15:04 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Jonatas L. Nogueira
On Tue, Feb 6, 2024 at 3:18 PM Ronald S. Bultje <rsbultje@gmail.com> wrote:
> Hi,
>
> On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <michael@niedermayer.cc
> >
> wrote:
>
> > 2. Deliverables
> > Patches submitted for review to the FFMPEG dev mailing list.
> >
>
> I think the goal is to get patches merged, not submitted.
>
┓┏┓┏┓┃
┛┗┛┗┛┃\○/
┓┏┓┏┓┃ / NOBODY
┛┗┛┗┛┃ノ)
┓┏┓┏┓┃ KNOWS
┛┗┛┗┛┃
┓┏┓┏┓┃
┛┗┛┗┛┃
┓┏┓┏┓┃
┃┃┃┃┃┃
┻┻┻┻┻┻
--
Vittorio
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 14:18 ` Ronald S. Bultje
2024-02-06 15:04 ` Vittorio Giovara
@ 2024-02-06 15:14 ` Michael Niedermayer
2024-02-06 15:21 ` Ronald S. Bultje
2024-02-06 15:59 ` Niklas Haas
2 siblings, 1 reply; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 15:14 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1660 bytes --]
On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > 2. Deliverables
> > Patches submitted for review to the FFMPEG dev mailing list.
> >
>
> I think the goal is to get patches merged, not submitted.
Yes but the individual developer cannot gurantee that.
Nor can we accept a patch before we see it
What the individual developer can gurantee is to provide a correct patch
fixing the problem.
This is similar to GSoC, the student has to finish the work that was
agreed. And pass teh mentors review. If the open source project decides
not to merge it thats not affecting the student.
I would never sign a contract that requires me to merge code into git master
and i would also not recommand anyone else to sign such contract. That said
i never had a customer had a problem with that. I do try to get code through
review its just that in rare cases someone fundamentally disagrees and
a change cannot be put in git master.
Its a recipe for conflict between teh community and whoever signed such
contract.
Also here we have STF which pays for maintaince, not for individual bug fixes
in master. So making an exception makes even less sense here
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 15:14 ` Michael Niedermayer
@ 2024-02-06 15:21 ` Ronald S. Bultje
2024-02-06 15:26 ` Michael Niedermayer
2024-02-06 16:04 ` Niklas Haas
0 siblings, 2 replies; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-06 15:21 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi,
On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> michael@niedermayer.cc>
> > wrote:
> >
> > > 2. Deliverables
> > > Patches submitted for review to the FFMPEG dev mailing list.
> > >
> >
> > I think the goal is to get patches merged, not submitted.
>
> Yes but the individual developer cannot gurantee that.
>
In a bad situation, someone could send unmergeable patches and they will
satisfy the legal requirement above for being paid out. I'm suggesting to
protect the project against that situation.
It's the difference between a goal of "a developer getting paid for work
done" or "ffmpeg maintenance being paid for". They are very closely related
but have slightly different finishes.
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 14:57 ` Vittorio Giovara
@ 2024-02-06 15:25 ` Michael Niedermayer
0 siblings, 0 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 15:25 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Jonatas L. Nogueira
[-- Attachment #1.1: Type: text/plain, Size: 1168 bytes --]
On Tue, Feb 06, 2024 at 03:57:39PM +0100, Vittorio Giovara wrote:
> On Tue, Feb 6, 2024 at 3:06 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > Hi all
> >
> > As Jonatan reminded the ML we need to provide SoWs if we want to
> > participate in STF-SPI
> >
> > We need one for each project (they do not need to list a person ATM)
> > but obviously we do need someone who will do the work
> >
> > I do belive they do need to list the money amount.
> > Thanks go to Pierre for helping me write template/example.
> > (converted from google docs and with some last minute edits)
> >
> > @Jonatan, is this below what SPI needs for each project ?
> >
>
> Correct me if I'm wrong but we still need the answer on "merge forks".
> Which ones, where, and why -- ie what if the community doesn't want or need
> any particular one?
I had no intend to do the "merge forks" task but give me a moment, ill try to fill
out the missing details
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 15:21 ` Ronald S. Bultje
@ 2024-02-06 15:26 ` Michael Niedermayer
2024-02-06 15:41 ` Michael Niedermayer
2024-02-06 16:04 ` Niklas Haas
1 sibling, 1 reply; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 15:26 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --]
On Tue, Feb 06, 2024 at 10:21:21AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > 2. Deliverables
> > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > >
> > >
> > > I think the goal is to get patches merged, not submitted.
> >
> > Yes but the individual developer cannot gurantee that.
> >
>
> In a bad situation, someone could send unmergeable patches and they will
> satisfy the legal requirement above for being paid out. I'm suggesting to
> protect the project against that situation.
yes
how foolproof do we want that wording to be ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 15:26 ` Michael Niedermayer
@ 2024-02-06 15:41 ` Michael Niedermayer
0 siblings, 0 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 15:41 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1584 bytes --]
On Tue, Feb 06, 2024 at 04:26:41PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 06, 2024 at 10:21:21AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <michael@niedermayer.cc>
> > wrote:
> >
> > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > > michael@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > 2. Deliverables
> > > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > > >
> > > >
> > > > I think the goal is to get patches merged, not submitted.
> > >
> > > Yes but the individual developer cannot gurantee that.
> > >
> >
> > In a bad situation, someone could send unmergeable patches and they will
> > satisfy the legal requirement above for being paid out. I'm suggesting to
> > protect the project against that situation.
>
> yes
> how foolproof do we want that wording to be ?
Random try:
1. Description
Fix 50% of the outstanding real issues
It is explicitly declared here, that if any issues require rewrites or redesigns of modules, these are outside the scope of this SoW.
2. Deliverables
Patches submitted for review to the FFMPEG dev mailing list. As well as taking care of all reasonable review comments.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 14:18 ` Ronald S. Bultje
2024-02-06 15:04 ` Vittorio Giovara
2024-02-06 15:14 ` Michael Niedermayer
@ 2024-02-06 15:59 ` Niklas Haas
2 siblings, 0 replies; 32+ messages in thread
From: Niklas Haas @ 2024-02-06 15:59 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Jonatas L. Nogueira
On Tue, 06 Feb 2024 09:18:20 -0500 "Ronald S. Bultje" <rsbultje@gmail.com> wrote:
> Hi,
>
> On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > 2. Deliverables
> > Patches submitted for review to the FFMPEG dev mailing list.
> >
>
> I think the goal is to get patches merged, not submitted.
On the other hand, having payment tied to merge, rather than submission,
encourages hasty merging, as well as holding hostage of patches from
developers one does not like.
I think that a significant contribution getting rejected late in the
review process due to insurmountable design flaws is a sufficiently rare
occurrence that the risk of somebody abusing this system is worth the
trade-offs of less stress for all involved.
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 15:21 ` Ronald S. Bultje
2024-02-06 15:26 ` Michael Niedermayer
@ 2024-02-06 16:04 ` Niklas Haas
2024-02-06 17:02 ` Ronald S. Bultje
1 sibling, 1 reply; 32+ messages in thread
From: Niklas Haas @ 2024-02-06 16:04 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <rsbultje@gmail.com> wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > 2. Deliverables
> > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > >
> > >
> > > I think the goal is to get patches merged, not submitted.
> >
> > Yes but the individual developer cannot gurantee that.
> >
>
> In a bad situation, someone could send unmergeable patches and they will
> satisfy the legal requirement above for being paid out. I'm suggesting to
> protect the project against that situation.
Unless I misunderstood you, what you are proposing protects the
Sovereign Tech Fund (aka German government), not the FFmpeg project.
This would only be a concern if we were funding work directly from the
(non-existant) FFmpeg treasury.
(And to be frank, paying somebody to write unmergeable FFmpeg patches is
probably a better use of government grant money than many of the
alternatives.)
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 16:04 ` Niklas Haas
@ 2024-02-06 17:02 ` Ronald S. Bultje
2024-02-06 18:17 ` Michael Niedermayer
2024-02-06 18:48 ` Niklas Haas
0 siblings, 2 replies; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-06 17:02 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi,
On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas <ffmpeg@haasn.xyz> wrote:
> On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <rsbultje@gmail.com>
> wrote:
> > Hi,
> >
> > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <
> michael@niedermayer.cc>
> > wrote:
> >
> > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > > michael@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > 2. Deliverables
> > > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > > >
> > > >
> > > > I think the goal is to get patches merged, not submitted.
> > >
> > > Yes but the individual developer cannot gurantee that.
> > >
> >
> > In a bad situation, someone could send unmergeable patches and they will
> > satisfy the legal requirement above for being paid out. I'm suggesting to
> > protect the project against that situation.
>
> Unless I misunderstood you, what you are proposing protects the
> Sovereign Tech Fund (aka German government), not the FFmpeg project.
> This would only be a concern if we were funding work directly from the
> (non-existant) FFmpeg treasury.
>
It was more about project reputation and the goals being pro-project rather
than pro-developer. Look at it this way: if patches get submitted but not
merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's
reputation to secure the funding. Subsequent funding rounds will be more
difficult. Requiring a merge protects the project against this bad
situation.
I understand that, hypothetically, if STF had funded SDR, this would be
problematic, because no payment is possible for work a majority of the
project's constituents doesn't want in. But maybe that ensures project
funding is requested for conservative sets of tasks that everyone agrees
are good for FFmpeg. So I don't see it as all bad. I don't think anyone is
realistically planning to find a GA or TC majority to block patches that
fix problems found by a static analyzer from going in, purely because it is
known that work was paid for? That doesn't sound realistic to me. We've
historically approved such patches without knowing it being declared
whether they were paid for or not.
But look at it from a higher level: you guys are asking for review of the
STF task proposals, and I'm trying to find problems where they exist. I
don't think the problem I find - or solution I propose (s/submit/merge/) -
is crazy. I'm OK with different "fixes" for this problem I'm pointing out.
But saying that it's not a problem... I disagree with that.
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 17:02 ` Ronald S. Bultje
@ 2024-02-06 18:17 ` Michael Niedermayer
2024-02-06 18:48 ` Paul B Mahol
` (2 more replies)
2024-02-06 18:48 ` Niklas Haas
1 sibling, 3 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 18:17 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 5594 bytes --]
Hi
On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas <ffmpeg@haasn.xyz> wrote:
>
> > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <rsbultje@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > > > michael@niedermayer.cc>
> > > > > wrote:
> > > > >
> > > > > > 2. Deliverables
> > > > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > > > >
> > > > >
> > > > > I think the goal is to get patches merged, not submitted.
> > > >
> > > > Yes but the individual developer cannot gurantee that.
> > > >
> > >
> > > In a bad situation, someone could send unmergeable patches and they will
> > > satisfy the legal requirement above for being paid out. I'm suggesting to
> > > protect the project against that situation.
> >
> > Unless I misunderstood you, what you are proposing protects the
> > Sovereign Tech Fund (aka German government), not the FFmpeg project.
> > This would only be a concern if we were funding work directly from the
> > (non-existant) FFmpeg treasury.
> >
>
> It was more about project reputation and the goals being pro-project rather
> than pro-developer. Look at it this way: if patches get submitted but not
> merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's
> reputation to secure the funding. Subsequent funding rounds will be more
> difficult.
> Requiring a merge protects the project against this bad
> situation.
"Requiring a merge" does not do that
because lets assume we have a SoW that says "merge to git master" is needed
now this merge is blocked by someone successfully
That means the SoW is not fullfilled, the developer is not payed and STF
has paid SPI. That would ruin FFmpegs reputation even more as
STF is unhappy (they paid and didnt get what was written in the SoW)
the developer was not paid, so she would definitly be unhappy
SPI as the one in the middle would also be in a very uncomfortable
position.
So i think we should make sure the conditions in the SoW are guranteed to be
achievable
>
> I understand that, hypothetically, if STF had funded SDR, this would be
> problematic, because no payment is possible for work a majority of the
> project's constituents doesn't want in. But maybe that ensures project
> funding is requested for conservative sets of tasks that everyone agrees
> are good for FFmpeg. So I don't see it as all bad. I don't think anyone is
> realistically planning to find a GA or TC majority to block patches that
> fix problems found by a static analyzer from going in, purely because it is
> known that work was paid for? That doesn't sound realistic to me. We've
> historically approved such patches without knowing it being declared
> whether they were paid for or not.
We have had multiple fixes blocked from going in.
There was the "i have a file this breaks, i will not share the file" cases
There where timeout fixes blocked because someone did not like some check
There was even general argumentation about OOM/Timeout fixes to be better
not done and rather running ffmpeg in a VM (which does not solve the problem
that the timeouts slow the fuzzer down)
Some fixes involving checking file extensions and similar also where not
popular
There was a time some people tried to block bugfixes if they printed an error
message. (thats why now none of my fixes prints an error message unless similar
cases do already)
I even remember that a paid bugfix in a demuxer (mov?) was rejected, the customer
was perfectly ok with that and paid me. I think i pointed it out to him
prior like i do with everyone nowadays that merge to git master cannot be
guranteed.
This is just what i remember at the spot.
Assuming the TC will solve it is brave because the TC is new and predates
most of the examples above.
I disencourage people from putting "merge into git master" as a
deliverable. It can get you burned in FFmpeg.
>
> But look at it from a higher level: you guys are asking for review of the
> STF task proposals, and I'm trying to find problems where they exist. I
> don't think the problem I find - or solution I propose (s/submit/merge/) -
> is crazy. I'm OK with different "fixes" for this problem I'm pointing out.
> But saying that it's not a problem... I disagree with that.
if "merge to git master" is a requirement then iam not participating
in this. The risk simply outweights the gain. I wont work for months to
then be at the mercy of not a single of 2000 subscribers posting some
"i object" and all 2000 know in this situation it would cause an
inconvenience to me.
I also recommand everyone else not to put their signature under a
SoW that lists things they cannot gurantee to achieve. I have once lost a large
customer from not considering adequately the FFmpeg communities ability to block
things. So its not even a hypothetical problem (no, noone knew it was paid work
it was not intentional)
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 18:17 ` Michael Niedermayer
@ 2024-02-06 18:48 ` Paul B Mahol
2024-02-07 12:16 ` Nicolas George
2024-02-06 20:53 ` Ronald S. Bultje
[not found] ` <1C84A3B8-51FD-4E46-8A61-B0A047606152@cosmin.at>
2 siblings, 1 reply; 32+ messages in thread
From: Paul B Mahol @ 2024-02-06 18:48 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Tue, Feb 6, 2024 at 7:17 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> Hi
>
> On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas <ffmpeg@haasn.xyz> wrote:
> >
> > > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <
> rsbultje@gmail.com>
> > > wrote:
> > > > Hi,
> > > >
> > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <
> > > michael@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > > > > michael@niedermayer.cc>
> > > > > > wrote:
> > > > > >
> > > > > > > 2. Deliverables
> > > > > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > > > > >
> > > > > >
> > > > > > I think the goal is to get patches merged, not submitted.
> > > > >
> > > > > Yes but the individual developer cannot gurantee that.
> > > > >
> > > >
> > > > In a bad situation, someone could send unmergeable patches and they
> will
> > > > satisfy the legal requirement above for being paid out. I'm
> suggesting to
> > > > protect the project against that situation.
> > >
> > > Unless I misunderstood you, what you are proposing protects the
> > > Sovereign Tech Fund (aka German government), not the FFmpeg project.
> > > This would only be a concern if we were funding work directly from the
> > > (non-existant) FFmpeg treasury.
> > >
> >
> > It was more about project reputation and the goals being pro-project
> rather
> > than pro-developer. Look at it this way: if patches get submitted but not
> > merged, is FFmpeg helped? Probably not. But money was spent using
> FFmpeg's
> > reputation to secure the funding. Subsequent funding rounds will be more
> > difficult.
>
> > Requiring a merge protects the project against this bad
> > situation.
>
> "Requiring a merge" does not do that
> because lets assume we have a SoW that says "merge to git master" is needed
> now this merge is blocked by someone successfully
> That means the SoW is not fullfilled, the developer is not payed and STF
> has paid SPI. That would ruin FFmpegs reputation even more as
> STF is unhappy (they paid and didnt get what was written in the SoW)
> the developer was not paid, so she would definitly be unhappy
> SPI as the one in the middle would also be in a very uncomfortable
> position.
>
> So i think we should make sure the conditions in the SoW are guranteed to
> be
> achievable
>
>
> >
> > I understand that, hypothetically, if STF had funded SDR, this would be
> > problematic, because no payment is possible for work a majority of the
> > project's constituents doesn't want in. But maybe that ensures project
> > funding is requested for conservative sets of tasks that everyone agrees
> > are good for FFmpeg. So I don't see it as all bad. I don't think anyone
> is
> > realistically planning to find a GA or TC majority to block patches that
> > fix problems found by a static analyzer from going in, purely because it
> is
> > known that work was paid for? That doesn't sound realistic to me. We've
> > historically approved such patches without knowing it being declared
> > whether they were paid for or not.
>
> We have had multiple fixes blocked from going in.
> There was the "i have a file this breaks, i will not share the file" cases
> There where timeout fixes blocked because someone did not like some check
> There was even general argumentation about OOM/Timeout fixes to be better
> not done and rather running ffmpeg in a VM (which does not solve the
> problem
> that the timeouts slow the fuzzer down)
> Some fixes involving checking file extensions and similar also where not
> popular
> There was a time some people tried to block bugfixes if they printed an
> error
> message. (thats why now none of my fixes prints an error message unless
> similar
> cases do already)
> I even remember that a paid bugfix in a demuxer (mov?) was rejected, the
> customer
> was perfectly ok with that and paid me. I think i pointed it out to him
> prior like i do with everyone nowadays that merge to git master cannot be
> guranteed.
> This is just what i remember at the spot.
>
> Assuming the TC will solve it is brave because the TC is new and predates
> most of the examples above.
>
> I disencourage people from putting "merge into git master" as a
> deliverable. It can get you burned in FFmpeg.
>
>
> >
> > But look at it from a higher level: you guys are asking for review of the
> > STF task proposals, and I'm trying to find problems where they exist. I
> > don't think the problem I find - or solution I propose (s/submit/merge/)
> -
> > is crazy. I'm OK with different "fixes" for this problem I'm pointing
> out.
> > But saying that it's not a problem... I disagree with that.
>
> if "merge to git master" is a requirement then iam not participating
> in this. The risk simply outweights the gain. I wont work for months to
> then be at the mercy of not a single of 2000 subscribers posting some
> "i object" and all 2000 know in this situation it would cause an
> inconvenience to me.
>
> I also recommand everyone else not to put their signature under a
> SoW that lists things they cannot gurantee to achieve. I have once lost a
> large
> customer from not considering adequately the FFmpeg communities ability to
> block
> things. So its not even a hypothetical problem (no, noone knew it was paid
> work
> it was not intentional)
>
If this is again about SDR, go ahead, merge it. I no longer care.
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 2
> "100% positive feedback" - "All either got their money back or didnt
> complain"
> "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
> _______________________________________________
> 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 17:02 ` Ronald S. Bultje
2024-02-06 18:17 ` Michael Niedermayer
@ 2024-02-06 18:48 ` Niklas Haas
1 sibling, 0 replies; 32+ messages in thread
From: Niklas Haas @ 2024-02-06 18:48 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Tue, 06 Feb 2024 12:02:51 -0500 "Ronald S. Bultje" <rsbultje@gmail.com> wrote:
> I understand that, hypothetically, if STF had funded SDR, this would be
> problematic, because no payment is possible for work a majority of the
> project's constituents doesn't want in.
As far as I understood, it was proposed that the GA votes on which SoWs
are sent to the STF. I don't think something as contentious as SDR would
survive such a vote to begin with.
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 18:17 ` Michael Niedermayer
2024-02-06 18:48 ` Paul B Mahol
@ 2024-02-06 20:53 ` Ronald S. Bultje
2024-02-06 21:23 ` Michael Niedermayer
[not found] ` <1C84A3B8-51FD-4E46-8A61-B0A047606152@cosmin.at>
2 siblings, 1 reply; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-06 20:53 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi,
On Tue, Feb 6, 2024 at 1:17 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> I wont work for months to
> then be at the mercy of not a single of 2000 subscribers posting some
> "i object" and all 2000 know in this situation it would cause an
> inconvenience to me.
>
That's a strawman version of how our review process works. I don't know why
you're bringing this up.
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 20:53 ` Ronald S. Bultje
@ 2024-02-06 21:23 ` Michael Niedermayer
2024-02-06 21:39 ` Ronald S. Bultje
2024-02-07 19:01 ` Leo Izen
0 siblings, 2 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 21:23 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2061 bytes --]
On Tue, Feb 06, 2024 at 03:53:55PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 1:17 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > I wont work for months to
> > then be at the mercy of not a single of 2000 subscribers posting some
> > "i object" and all 2000 know in this situation it would cause an
> > inconvenience to me.
> >
>
> That's a strawman version of how our review process works. I don't know why
> you're bringing this up.
Our review process works by any developer who wants to, review and or comment
submitted patches. These are generally people who are active in FFmpeg development.
But anyone of the subscribers can comment and we generally encourage others
to comment if they have something to say.
Its true anyone of 2000 people could block a patch. This is not neccessary
for the argument at all though.
Even if it is just the 30 most active developers, the problem is still there.
I cannot gurantee that none of them will block a patch.
A wide range of different developers have had
disagreemnets over time. And disagreements have frequently blocked some
patches. As a person signing a SoW i cannot gurantee that noone will block
the work from being merged into git master.
Thus that is something i cannot sign.
What i can and did and do suggest is
"Patches submitted for review to the FFMPEG dev mailing list. As well as taking care of all reasonable review comments."
If "all reasonable review comments" is not enough then what are other
review comments ? Obviously it must be UNreasonable review comments
and no, i will not sign that.
Iam not going to spend the little free time i have working on this and
then have litterally "UNreasonable review comments" that iam contratually
obliged to somehow handle
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 21:23 ` Michael Niedermayer
@ 2024-02-06 21:39 ` Ronald S. Bultje
2024-02-06 23:04 ` Michael Niedermayer
2024-02-07 19:01 ` Leo Izen
1 sibling, 1 reply; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-06 21:39 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi,
On Tue, Feb 6, 2024 at 4:23 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> What i can and did and do suggest is
> "Patches submitted for review to the FFMPEG dev mailing list. As well as
> taking care of all reasonable review comments."
>
> If "all reasonable review comments" is not enough then what are other
> review comments ? Obviously it must be UNreasonable review comments
>
That's again a strawman. Who decides what is reasonable? Assuming this is
some community-approved process - e.g. the TC, then how is this different
from going through TC to get the patch merged?
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 21:39 ` Ronald S. Bultje
@ 2024-02-06 23:04 ` Michael Niedermayer
2024-02-07 1:38 ` Ronald S. Bultje
0 siblings, 1 reply; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-06 23:04 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2525 bytes --]
On Tue, Feb 06, 2024 at 04:39:51PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 4:23 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > What i can and did and do suggest is
> > "Patches submitted for review to the FFMPEG dev mailing list. As well as
> > taking care of all reasonable review comments."
> >
> > If "all reasonable review comments" is not enough then what are other
> > review comments ? Obviously it must be UNreasonable review comments
> >
>
> That's again a strawman. Who decides what is reasonable? Assuming this is
> some community-approved process - e.g. the TC, then how is this different
> from going through TC to get the patch merged?
I think you should sign a SoW that has "Merged in git master" as a
Deliverable for 300 commits you spend half a year of ALL your free time on
This would be best. I will not sign that and it seems you are ok with it.
But lets continue the argument:
Let us first assume there is a blocked set of patches because
otherwise obviously none of this matters.
If you have a contract that says you get payed when code is merged then
you cannot submit an invoice before the code is merged so its up
to you to make that happen. Doing months long debates on the ML bringing
things up to the TC, and there is no gurantee you will succeed or how
long this process would take, it could take months or years. You might
never get payed as the TC might just decide not to agree with you or
might not come to a conclusion.
If you have a contract that says you get payed when you took care of all
reasonable comments then you can submit an invoice once you done that
with documentation what and why is unreasonable.
Now you need to be paid, you can just sit back and wait
In the background FFmpeg and SPI might invoke the TC to verify the
list claimed unreasonable.
If the TC agrees you get paid, and the patches maybe would be applied
If the TC disagrees there would be more work before you are paid
if the TC takes months or comes up with no conclusion. You will need
to be paid
thx
PS: do you have a single person willing to sign this Deliverable you
want ?
If not, how will the STF thing work ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 23:04 ` Michael Niedermayer
@ 2024-02-07 1:38 ` Ronald S. Bultje
2024-02-07 12:58 ` Michael Niedermayer
0 siblings, 1 reply; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-07 1:38 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi,
On Tue, Feb 6, 2024 at 6:04 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> I think you should sign a SoW that has "Merged in git master" as a
> Deliverable
>
I already did. It was fine.
> PS: do you have a single person willing to sign this Deliverable you
> want ?
> If not, how will the STF thing work ?
>
You're asking for community input for your proposal, I gave comments as
requested. It's OK to disagree on things, happens all the time. You can A)
ignore my suggestions and submit the proposal to STF anyway, B) submit a
proposal to STF as yourself rather than as FFmpeg (but for the same tasks,
on FFmpeg), C) submit a proposal using another company/non-profit (e.g.
fflabs), D) not submit a proposal to STF, or E) something else ???
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
[not found] ` <1C84A3B8-51FD-4E46-8A61-B0A047606152@cosmin.at>
@ 2024-02-07 2:28 ` Cosmin Stejerean via ffmpeg-devel
0 siblings, 0 replies; 32+ messages in thread
From: Cosmin Stejerean via ffmpeg-devel @ 2024-02-07 2:28 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Cosmin Stejerean
> On Feb 6, 2024, at 10:17 AM, Michael Niedermayer <michael@niedermayer.cc> wrote:
>
> if "merge to git master" is a requirement then iam not participating
> in this. The risk simply outweights the gain. I wont work for months to
> then be at the mercy of not a single of 2000 subscribers posting some
> "i object" and all 2000 know in this situation it would cause an
> inconvenience to me.
It doesn't have to be all or nothing. In addition to having smaller milestones so that it's not months of work that are at risk, the milestones can also split between things like initial design is ready, a functional prototype is built, the initial patchset of the final solution is ready for review, the work is merged, etc.
I believe the benefit of picking experienced developers (with over 100 authored commits) is that the work is done by people that have demonstrated they know how to get their changes merged. And they should have a good intuition for what kind of work is going to be accepted and what kind of work won't. Worst case scenario they can take it up wih the TC although building consensus on the approach ahead of time rather than after months of work might be preferable.
At the same time this work will be done by established developers who presumably have much more to lose from trying to game the system than they will get paid for a one-off project. If they do a good job there will likely be more work going their way in the future. If they try to cheat there probably won't be. So it should be reasonable to expect some good faith payments along the way even before everything is merged.
Given all that perhaps 75% is due at the time the work is ready for review and 25% after it is merged, etc. Whatever the split I do think it's important to have a reasonable part of the payment tied to getting the work merged, while at the same time not expecting developers to work for months and have 100% of the funds tied up in contentious patch review.
- Cosmin
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 18:48 ` Paul B Mahol
@ 2024-02-07 12:16 ` Nicolas George
2024-02-07 13:11 ` Rémi Denis-Courmont
0 siblings, 1 reply; 32+ messages in thread
From: Nicolas George @ 2024-02-07 12:16 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Paul B Mahol (12024-02-06):
> If this is again about SDR, go ahead, merge it. I no longer care.
You should care. But you should care by being FOR it, not AGAINST.
The people who oppose SDR are the same libav people who are disgusting
you and me and others away from the project with their authoritarian
attitude, their behaving like on conquered ground, their disregard for
features that only serve a handful of users but are crucial for them
because they cannot be found in any other software than FFmpeg.
These people are killing the project, we should oppose them whenever we
have the courage.
Regards,
--
Nicolas George
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 1:38 ` Ronald S. Bultje
@ 2024-02-07 12:58 ` Michael Niedermayer
2024-02-07 13:08 ` Ronald S. Bultje
0 siblings, 1 reply; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-07 12:58 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2376 bytes --]
On Tue, Feb 06, 2024 at 08:38:13PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 6:04 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > I think you should sign a SoW that has "Merged in git master" as a
> > Deliverable
> >
>
> I already did. It was fine.
of course its fine 9 out of 10 times
but 1 out of 10 times the customer is unhappy and you are unhappy.
I like being transparent and explain this possibility to the customer/buisness
partner.
because no matter whats written in a contract, sometimes some patches cannot
be merged in git master.
>
>
> > PS: do you have a single person willing to sign this Deliverable you
> > want ?
> > If not, how will the STF thing work ?
> >
>
> You're asking for community input for your proposal, I gave comments as
> requested. It's OK to disagree on things, happens all the time.
yes, but i was hoping we could find something we both agree on
> You can A)
> ignore my suggestions and submit the proposal to STF anyway,
> B) submit a
> proposal to STF as yourself rather than as FFmpeg (but for the same tasks,
> on FFmpeg),
> C) submit a proposal using another company/non-profit (e.g.
> fflabs),
> D) not submit a proposal to STF,
> or E) something else ???
Its more complex
Theres the person writing a SoW for work he wants to do.
Theres the person who accepts the SoW in FFmpeg
Theres the person who passes accepted SoW on to SPI/STF
Iam sadly involved in more than one role here.
If everyone including you agree on whats written in the SoW, i think
its ok but if you disagree I cannot override or bypass that.
That said, we from the point of view of FFmpeg should not
promise STF that we can merge code in git master before its written.
It could fail and would make the project look bad
STF is about maintainance, analyzing bugs, fixing bugs, submitting patches
reviewing patches maybe.
Promising them that the whole community will accept every change. Which is
what "merge to git master" is. Is not needed
In fact it might even be counter productive. STF probabyl does not want things
to be merged that people do not agree on.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Nations do behave wisely once they have exhausted all other alternatives.
-- Abba Eban
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 12:58 ` Michael Niedermayer
@ 2024-02-07 13:08 ` Ronald S. Bultje
2024-02-07 14:44 ` Michael Niedermayer
2024-02-08 4:08 ` Michael Niedermayer
0 siblings, 2 replies; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-07 13:08 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi Michael,
On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> Theres the person writing a SoW for work he wants to do.
> Theres the person who accepts the SoW in FFmpeg
> Theres the person who passes accepted SoW on to SPI/STF
>
> Iam sadly involved in more than one role here.
>
I think this is what Vittorio was referring to when he said this might be
problematic. This is essentially what conflict-of-interest means. It
doesn't mean that you're a bad person or doing something wrong, it simply
means that there's overlapping goals. For example, in this case, there
might be your personal goals ("get paid for work") vs the project goals
("get money for maintenance"). They're (partially) overlapping but not
equal, because they're different angles of the same situation.
Sometimes there is no ideal solution that satisfies everyone. As I said
before, that's normal and that's OK.
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 12:16 ` Nicolas George
@ 2024-02-07 13:11 ` Rémi Denis-Courmont
0 siblings, 0 replies; 32+ messages in thread
From: Rémi Denis-Courmont @ 2024-02-07 13:11 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Le 7 février 2024 14:16:51 GMT+02:00, Nicolas George <george@nsup.org> a écrit :
>Paul B Mahol (12024-02-06):
>> If this is again about SDR, go ahead, merge it. I no longer care.
>
>You should care. But you should care by being FOR it, not AGAINST.
>
>The people who oppose SDR are the same libav people who are disgusting
>you and me and others away from the project with their authoritarian
>attitude, their behaving like on conquered ground, their disregard for
>features that only serve a handful of users but are crucial for them
>because they cannot be found in any other software than FFmpeg.
>
>These people are killing the project, we should oppose them whenever we
>have the courage.
*Yawn*. Sure, go ahead and make your own Democratic People's fork of FFmpeg without the corporate capitalist oppressors.
You can even make a downstream of librempeg but with SDR. Win-win-win.
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 13:08 ` Ronald S. Bultje
@ 2024-02-07 14:44 ` Michael Niedermayer
2024-02-07 17:31 ` Ronald S. Bultje
2024-02-08 4:08 ` Michael Niedermayer
1 sibling, 1 reply; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-07 14:44 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2245 bytes --]
On Wed, Feb 07, 2024 at 08:08:34AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > Theres the person writing a SoW for work he wants to do.
> > Theres the person who accepts the SoW in FFmpeg
> > Theres the person who passes accepted SoW on to SPI/STF
> >
> > Iam sadly involved in more than one role here.
> >
>
> I think this is what Vittorio was referring to when he said this might be
> problematic. This is essentially what conflict-of-interest means. It
> doesn't mean that you're a bad person or doing something wrong, it simply
> means that there's overlapping goals. For example, in this case, there
> might be your personal goals ("get paid for work") vs the project goals
> ("get money for maintenance"). They're (partially) overlapping but not
> equal, because they're different angles of the same situation.
>
> Sometimes there is no ideal solution that satisfies everyone. As I said
> before, that's normal and that's OK.
Yes, so the question is what do we do here?
Can you accept that "merge to git master" is not a deliverable ?
(at least in the february 2024 iteration)
Alternatively i can offer that i work on merging the code to git master
on a euro per hour rate with a limit. But again the actual merge is
not guranteed
failing that, i see as only options left to either do a quick vote on
the finished Coverity bug fixing SoW, so a simple "is this text ok", and if
yes nothing anyone says later can create another problem.
Or I can resign from my involvement in managing STF in february and someone
else can take that over. I never really wanted to manage it anyway, i was
just trying to help to get 200k€ to FFmpeg developers for their relentless
volunteer maintaince of the project so they would have something in exchange
for all they gave up of their own time
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 14:44 ` Michael Niedermayer
@ 2024-02-07 17:31 ` Ronald S. Bultje
0 siblings, 0 replies; 32+ messages in thread
From: Ronald S. Bultje @ 2024-02-07 17:31 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Hi,
On Wed, Feb 7, 2024 at 9:44 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> [..] i see as only options left to either do a quick vote on
> the finished Coverity bug fixing SoW, so a simple "is this text ok", and if
> yes nothing anyone says later can create another problem.
>
That seems reasonable.
Ronald
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-06 21:23 ` Michael Niedermayer
2024-02-06 21:39 ` Ronald S. Bultje
@ 2024-02-07 19:01 ` Leo Izen
2024-02-07 19:53 ` Michael Niedermayer
2024-02-08 12:32 ` Nicolas George
1 sibling, 2 replies; 32+ messages in thread
From: Leo Izen @ 2024-02-07 19:01 UTC (permalink / raw)
To: ffmpeg-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 570 bytes --]
On 2/6/24 16:23, Michael Niedermayer wrote:
> Its true anyone of 2000 people could block a patch. This is not neccessary
> for the argument at all though.
I don't think this is really a fair statement to make. We have lots of
potential reviewers subscribed to this list but very few people actually
review code, and those that do review code are expected to provide some
sort of technical objection or reason why it shouldn't be merged. A
random subscriber without commit access posting "Nak" on a patch without
explaining why isn't grounds to block it.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 19:01 ` Leo Izen
@ 2024-02-07 19:53 ` Michael Niedermayer
2024-02-08 12:32 ` Nicolas George
1 sibling, 0 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-07 19:53 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 877 bytes --]
On Wed, Feb 07, 2024 at 02:01:35PM -0500, Leo Izen wrote:
> On 2/6/24 16:23, Michael Niedermayer wrote:
> > Its true anyone of 2000 people could block a patch. This is not neccessary
> > for the argument at all though.
>
> I don't think this is really a fair statement to make. We have lots of
> potential reviewers subscribed to this list but very few people actually
> review code, and those that do review code are expected to provide some sort
> of technical objection or reason why it shouldn't be merged. A random
> subscriber without commit access posting "Nak" on a patch without explaining
> why isn't grounds to block it.
you are correct
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Elect your leaders based on what they did after the last election, not
based on what they say before an election.
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 13:08 ` Ronald S. Bultje
2024-02-07 14:44 ` Michael Niedermayer
@ 2024-02-08 4:08 ` Michael Niedermayer
1 sibling, 0 replies; 32+ messages in thread
From: Michael Niedermayer @ 2024-02-08 4:08 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1659 bytes --]
On Wed, Feb 07, 2024 at 08:08:34AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > Theres the person writing a SoW for work he wants to do.
> > Theres the person who accepts the SoW in FFmpeg
> > Theres the person who passes accepted SoW on to SPI/STF
> >
> > Iam sadly involved in more than one role here.
> >
>
> I think this is what Vittorio was referring to when he said this might be
> problematic. This is essentially what conflict-of-interest means. It
> doesn't mean that you're a bad person or doing something wrong, it simply
> means that there's overlapping goals. For example, in this case, there
> might be your personal goals ("get paid for work") vs the project goals
> ("get money for maintenance"). They're (partially) overlapping but not
> equal, because they're different angles of the same situation.
>
> Sometimes there is no ideal solution that satisfies everyone. As I said
> before, that's normal and that's OK.
Yes
To reduce this conflict of interrest problem. I asked Pierre if he can
take over the leading role in the current FFmpeg - STF/SPI thing
He was the only person who contacted me and helped with writing the SoW
example/template. He clearly has a more solid understanding of the SoW
process than i do, so i think that helps beyond just a reduction
of conflict of interrest.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
[-- 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-07 19:01 ` Leo Izen
2024-02-07 19:53 ` Michael Niedermayer
@ 2024-02-08 12:32 ` Nicolas George
2024-02-08 12:42 ` epirat07
1 sibling, 1 reply; 32+ messages in thread
From: Nicolas George @ 2024-02-08 12:32 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Leo Izen (12024-02-07):
> I don't think this is really a fair statement to make. We have lots of
> potential reviewers subscribed to this list but very few people actually
> review code, and those that do review code are expected to provide some sort
> of technical objection or reason why it shouldn't be merged. A random
> subscriber without commit access posting "Nak" on a patch without explaining
> why isn't grounds to block it.
A random subscriber cannot do that, but if they are thick as thieves
with the people who managed to gain control of the committees, so that
they can be sure the tech will side with them and they can threaten you
if you point that their objections are flimsy a little too clearly, then
they can block your patch with a vague “it does not belong in ffmpeg”,
that does require a lot less effort than reviewing.
Regards,
--
Nicolas George
_______________________________________________
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".
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [FFmpeg-devel] STF SoWs
2024-02-08 12:32 ` Nicolas George
@ 2024-02-08 12:42 ` epirat07
0 siblings, 0 replies; 32+ messages in thread
From: epirat07 @ 2024-02-08 12:42 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On 8 Feb 2024, at 13:32, Nicolas George wrote:
> Leo Izen (12024-02-07):
>> I don't think this is really a fair statement to make. We have lots of
>> potential reviewers subscribed to this list but very few people actually
>> review code, and those that do review code are expected to provide some sort
>> of technical objection or reason why it shouldn't be merged. A random
>> subscriber without commit access posting "Nak" on a patch without explaining
>> why isn't grounds to block it.
>
> A random subscriber cannot do that, but if they are thick as thieves
> with the people who managed to gain control of the committees, so that
Can you maybe stop crying about that things did not went your way on every
topic slightly related to FFmpeg „politics“ on this list?
This is getting so annoying… The amount of times I had to read your
absurd insinuations about there being some „conspiracy“ to take over
the project…
> they can be sure the tech will side with them and they can threaten you
> if you point that their objections are flimsy a little too clearly, then
> they can block your patch with a vague “it does not belong in ffmpeg”,
> that does require a lot less effort than reviewing.
>
> Regards,
>
> --
> Nicolas George
> _______________________________________________
> 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".
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2024-02-08 12:42 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-06 2:06 [FFmpeg-devel] STF SoWs Michael Niedermayer
2024-02-06 14:18 ` Ronald S. Bultje
2024-02-06 15:04 ` Vittorio Giovara
2024-02-06 15:14 ` Michael Niedermayer
2024-02-06 15:21 ` Ronald S. Bultje
2024-02-06 15:26 ` Michael Niedermayer
2024-02-06 15:41 ` Michael Niedermayer
2024-02-06 16:04 ` Niklas Haas
2024-02-06 17:02 ` Ronald S. Bultje
2024-02-06 18:17 ` Michael Niedermayer
2024-02-06 18:48 ` Paul B Mahol
2024-02-07 12:16 ` Nicolas George
2024-02-07 13:11 ` Rémi Denis-Courmont
2024-02-06 20:53 ` Ronald S. Bultje
2024-02-06 21:23 ` Michael Niedermayer
2024-02-06 21:39 ` Ronald S. Bultje
2024-02-06 23:04 ` Michael Niedermayer
2024-02-07 1:38 ` Ronald S. Bultje
2024-02-07 12:58 ` Michael Niedermayer
2024-02-07 13:08 ` Ronald S. Bultje
2024-02-07 14:44 ` Michael Niedermayer
2024-02-07 17:31 ` Ronald S. Bultje
2024-02-08 4:08 ` Michael Niedermayer
2024-02-07 19:01 ` Leo Izen
2024-02-07 19:53 ` Michael Niedermayer
2024-02-08 12:32 ` Nicolas George
2024-02-08 12:42 ` epirat07
[not found] ` <1C84A3B8-51FD-4E46-8A61-B0A047606152@cosmin.at>
2024-02-07 2:28 ` Cosmin Stejerean via ffmpeg-devel
2024-02-06 18:48 ` Niklas Haas
2024-02-06 15:59 ` Niklas Haas
2024-02-06 14:57 ` Vittorio Giovara
2024-02-06 15:25 ` Michael Niedermayer
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