On Tue, Feb 6, 2024 at 7:17 PM Michael Niedermayer <mich...@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 <ffm...@haasn.xyz> wrote: > > > > > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" < > rsbul...@gmail.com> > > > wrote: > > > > Hi, > > > > > > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer < > > > mich...@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 < > > > > > mich...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".