* [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 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 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 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 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 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-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 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 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-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-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 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
[parent not found: <1C84A3B8-51FD-4E46-8A61-B0A047606152@cosmin.at>]
* 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 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 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 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: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
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