[FFmpeg-devel] Sovereign Tech Fund

[Zhao Zhili]

> On Feb 5, 2024, at 18:21, Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> On Wed, Jan 31, 2024 at 09:55:00PM +0000, Kieran Kunhya wrote:
>> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis at gmail.com>
>> wrote:
>> 
>>> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
>>>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
>>> 
>>> Not to derail this fine thread, but what forks does the Merge Forks
>>> project refer to?
>>> 
>>> - Derek
>>> 
>> 
>> I also added a note that 70 USD for coverity is way too much. I picked a
>> random issue 1503073 and within a minute saw that it was a false positive.
>> I don't deserve 70USD for that.
> 
> I fixed 2 coverity issues yesterday and it took me over 3 hours
> I cant do this for 70USD per issue
> (you can see the ML for the 2 patches)
> 
> In the first, the issue depended on fbw_channels to be 0.
> If you look at its initialization that is possible if you have a
> mono LFE channel but is that possible and can the code be reached
> in that case.
> For someone who hasnt worked at that specific code it takes some time
> to build an argument that this should not be possible
> 
> The second issue, its obvious a bug but how do we even reach that code?
> No fate tests ....
> luckily there are examples in the docs but it took me several tries to
> get the code to execute with similar testcases.
> now looking at it, i suspect the patch i posted probably should be split
> so we need a 2nd iteration
> and looking at the clock when i posted this and when i started yesterday
> fact is it was 3-4h work for these 2 issues

I think work on two to three issues in spare time per day is a rough but
reasonable number, with one to two being easy and one from medium
to hard. 210$ isn’t that much, especially for overtime pay. Many people
have working on open source for free (as in beer) for many years, but it
doesn’t mean that their work not worth like 70 $.

> 
> did i pick these randomly? no, i started frm the top and skiped a few
> i really did not want to work on like the flac parser.
> 
> Some coverity isssues are dead easy and need seconds to categorize
> or even fix. But for others its difficult
> 
> Also to categorize coverity issues one needs to understand the affectd
> code. coverity telling you that after 355 conditions theres a out of
> array access, you need to know if the 355 conditions are inconsistant
> and contradicting. If they contradict its a false positive otherwise
> its a bug.
> similar when you check the return code of a function most of the time
> coverity will create an issue for cases where its not checked. Thats
> trivial to fix IF you know the code. But IF you do not know the code
> that can some decent time too. And i think noone knows all code.
> 
> Either way, iam interrested in helping with coverity work while
> at the same time this environment where peole finger point and say
> "is way too much" is something i dont feel comfortable to work in.
> 
> maybe doing it per hour instead of per issue is a safer way
> 
> thx
> 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".