Re: [FFmpeg-devel] Sovereign Tech Fund
Hi all, We are offered to apply for a sponsorship of FFmpeg by the Sovereign Tech Fund (STF). Please read the following to get a better understanding what STF is about: (In short it is about maintenance and sustainability, not features) https://www.sovereigntechfund.de/programs/applications As some probably already know, Thilo has worked with STF to work out many details of this. SPI will handle the financials for FFmpeg. Everyone willing to benefit from this sponsorship must not be a US sanctioned entity or in a US sanctioned country. And must sign a contractor agreement and simplified SoW with SPI. "A SOW purpose is to protect the contracted from doing a work and not getting paid, and to protect the contractor from paying for a work which wasn't wanted" At this point, what we need is a list of Projects so we can submit an application to STF at or before 12th Feb. (at the 14th they have a meeting and will review our submission) our application has been fully accepted, covering all the project proposals as listed in [1]. We were asked to align our public / social media announcement with STF which happens after the contracts are finalized, presumably end of April. Once these are done and set, I'll post a patch for a news entry which we can also put into the social media channels we have. Cheers, Thilo [1] http://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024#STFApplication ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
This is the courtesy reminder we've agreed on, to remember there's a week left to finish the Scope of Work if FFmpeg wishes to deliver it by February 12th as requested by STF. Att., Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 21:16 Stefano Sabatini wrote: > On date Thursday 2024-02-01 00:15:03 +0100, Stefano Sabatini wrote: > > José already provided and excellent summary from his side. On my side > > I meant Jonatas, sorry. > ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> On Feb 5, 2024, at 18:21, Michael Niedermayer wrote: > > On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote: >> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis >> 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@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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> 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. > So you make an RFC but you only want comments that agree with you? > maybe doing it per hour instead of per issue is a safer way > I see the penny is finally starting to drop. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis > 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 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 signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi, Le 4 février 2024 21:28:44 GMT+02:00, Michael Niedermayer a écrit : >On Sun, Feb 04, 2024 at 03:38:43PM +0100, Rémi Denis-Courmont wrote: >> Hi, >> >> Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer >> a écrit : >> >Hi >> > >> >As said on IRC, i thought people knew it, but ‘the same person as before’ >> >is Thilo. >> > >> >Ive updated the price design suggestion for the merge task, its 16€ / >> >commit limited to 50k€ >> >this comes from looking at pauls fork which has around 500 commits in 2 >> >months thus >> >250 commits per month, 12 months, and if we allocate 50k that end with >> >roughly 16€ / commit >> >if activity stays equal. >> >> It's very different if we're talking about librempeg or some other >> unspecified fork. I could make a fork that removes MMX et al, and claim that >> I'm merging a fork. > >There are so many reasons why this wouldnt work >(first you would have to lie, i dont think you would, > then it would not be left that way on the wiki, > not being sent to STF that way > and not being accepted by STF and more) > >But assuming one could get away with that in the short term >Why would anyone do something like this to destroy our all opertunity >to obtains grants in the future ? I don't know. That was purely an example, and I prefer to be the fictional bad guy in my examples, so nobody else feels insulted. But you can't blame people for being distrustful when a proposal is brought forward on short deadlines even though it was privately known for months. >> Indeed I don't think that a semiformal open-source community with a lot of >> strong and varied opinions will carry such dotting of all i's very >> effectively. That has been one of the arguments for delegating this to a >> contracting IT company rather than to FFmpeg-devel and SPI. > >If the FFmpeg team can make decissions about what to fund then we do not need >any contracting IT company. Let's face it: FFmpeg is not the healthiest of open-source communities as of now. But that's not even relevant here: OSS communities are typically focused on development and maybe support and promotion, *not* HR and payroll, nor waterfall-style project management. Ergo, there would be no shame in conceding that FFmpeg would suck at those tasks, and a company whose job those things essentially are would be more effective at it. And I'm not saying this out of self-interest, just pragmatism (call it cynicism if you will). >OTOH If the FFmpeg team is not able to make decissions, thats a far bigger >problem and it needs to be understood and corrected I don't think the technical development lists of an OSS community should concern themselves with funding matters. Well-funded foundations surely need to concern themselves with this, but they don't mix it with development. And FFmpeg is not sl well-funded in the first place. > Because whoever controlls the income of developers >effectively controlls the project. As long as there are several parties involved, and a single trust doesn't dominate the GA and the TC, I don't see that as a major problem. Or rather, it's a lesser problem than loosing competent developers because they need to work on something else to earn their living. >An emloyee has to do what she is being told be her employer. So if the main >developers >become employees payed to work on FFmpeg that would hand FFmpeg to some CEO on >a >silver plate, 20€ are not remotely enough for that to happen. You'd need 2-3 orders of magnitude larger investment, without competition, to get there at minimum. So I don't see a risk here. But it's up to Thilo really, if he insists on going through SPI or not applying for STF at all. >This would change FFmpeg from a Free software project to a commercial company. >I do NOT agree to this, and i belive many others also do not agree. I think a lot of people would rather get paid to work on Ffmpeg, and would in fact contribute more effectively if they were. And conversely, quite a few contributors seem to be acting for their commercial employer already. Also, as a consultant or maybe an associate for FFlabs, it's a rather contradictory position for you to hold. ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Sun, Feb 04, 2024 at 03:38:43PM +0100, Rémi Denis-Courmont wrote: > Hi, > > Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer > a écrit : > >Hi > > > >As said on IRC, i thought people knew it, but ‘the same person as before’ is > >Thilo. > > > >Ive updated the price design suggestion for the merge task, its 16€ / commit > >limited to 50k€ > >this comes from looking at pauls fork which has around 500 commits in 2 > >months thus > >250 commits per month, 12 months, and if we allocate 50k that end with > >roughly 16€ / commit > >if activity stays equal. > > It's very different if we're talking about librempeg or some other > unspecified fork. I could make a fork that removes MMX et al, and claim that > I'm merging a fork. There are so many reasons why this wouldnt work (first you would have to lie, i dont think you would, then it would not be left that way on the wiki, not being sent to STF that way and not being accepted by STF and more) But assuming one could get away with that in the short term Why would anyone do something like this to destroy our all opertunity to obtains grants in the future ? > > >The task has ATM no developer on it. If a developer adds himself, he can > >change teh task > >and specify what he proposes to merge. > > > >I am totally perplexed why every dot on every i is such a big thing. > > That is the whole point of a statement of work. And I agree that it's tedious > and possibly outright annoying... > > Indeed I don't think that a semiformal open-source community with a lot of > strong and varied opinions will carry such dotting of all i's very > effectively. That has been one of the arguments for delegating this to a > contracting IT company rather than to FFmpeg-devel and SPI. If the FFmpeg team can make decissions about what to fund then we do not need any contracting IT company. OTOH If the FFmpeg team is not able to make decissions, thats a far bigger problem and it needs to be understood and corrected But not only this "delegating this to a contracting IT company" really means having a random CEO make the decissions about FFmpeg instead of the GA or community. It is unlikely this will be accepted by the GA. And if accepted it would be the end of FFmpeg. We would have not even sold FFmpeg we would have given it for free to some company. Because whoever controlls the income of developers effectively controlls the project. An emloyee has to do what she is being told be her employer. So if the main developers become employees payed to work on FFmpeg that would hand FFmpeg to some CEO on a silver plate, This would change FFmpeg from a Free software project to a commercial company. I do NOT agree to this, and i belive many others also do not agree. I am happy if we can get people payed continuously from grants and other sources but never should FFmpeg give up its autonomy Also we have "a lot of strong and varied opinions" but IMHO that is not the problem here. The problem is distrust. Using an "contracting IT company" will make this worse, First we will not agree on it and if we do, we will end with a fork, whoever is not "friends" with the CEO of that company will leave. SPI or a similar entity gives us the transparency where a group of people who distrust each other can move forward without the need to trust a 3rd party Everyone can add their entry to the wiki, everyone has the same rights to edit it. Everyone elected the TC. I dont think a failure of SPI-STF will result in the money going next time to a contracting IT company. We have the opertunity to move forward together here. Or we can choose not to move forward Or we can choose not to do it together Thats fundamentally the choices. In a mathematical sense, there are no other choices I favor moving forward together! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi, Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer a écrit : >Hi > >As said on IRC, i thought people knew it, but ‘the same person as before’ is >Thilo. > >Ive updated the price design suggestion for the merge task, its 16€ / commit >limited to 50k€ >this comes from looking at pauls fork which has around 500 commits in 2 months >thus >250 commits per month, 12 months, and if we allocate 50k that end with roughly >16€ / commit >if activity stays equal. It's very different if we're talking about librempeg or some other unspecified fork. I could make a fork that removes MMX et al, and claim that I'm merging a fork. >The task has ATM no developer on it. If a developer adds himself, he can >change teh task >and specify what he proposes to merge. > >I am totally perplexed why every dot on every i is such a big thing. That is the whole point of a statement of work. And I agree that it's tedious and possibly outright annoying... Indeed I don't think that a semiformal open-source community with a lot of strong and varied opinions will carry such dotting of all i's very effectively. That has been one of the arguments for delegating this to a contracting IT company rather than to FFmpeg-devel and SPI. >We are doing GSoC for a decade and noone cared about voting about anything in >it. Again, I don't think it's a fair comparison. GSoC rules are a given set by Google. Maintenance is not allowed nor are vague broadly defined tasks. Also the mentor payment is not really a proper compensation, nor is it intended to be. >The difference here is FFmpeg developers are benefiting from the money. That's a pretty major difference. >We send an application and a scope of work. That's exactly why we need to have a precise scope of work to vote on this. ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi On Sun, Feb 04, 2024 at 11:02:30AM +0100, J. Dekker wrote: > > > On Sun, Feb 4, 2024, at 10:49, Rémi Denis-Courmont wrote: > > Hi, > > > > I don't believe it is appropriate to hold the vote before Derek's > > question is addressed. > > > > We don't really know what we're voting on here. > > > > Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis > > a écrit : > >>On 1/31/2024 9:44 PM, Derek Buitenhuis 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? > >> > >>I do not believe this has been answered. > >> > >>- Derek > > > The vote is unclear for me and also it was not explained who ‘the same person > as before’ is, no reply or answer to this either. Hope Michael can clear this > up. As said on IRC, i thought people knew it, but ‘the same person as before’ is Thilo. Ive updated the price design suggestion for the merge task, its 16€ / commit limited to 50k€ this comes from looking at pauls fork which has around 500 commits in 2 months thus 250 commits per month, 12 months, and if we allocate 50k that end with roughly 16€ / commit if activity stays equal. The task has ATM no developer on it. If a developer adds himself, he can change teh task and specify what he proposes to merge. I am totally perplexed why every dot on every i is such a big thing. We are doing GSoC for a decade and noone cared about voting about anything in it. The difference here is FFmpeg developers are benefiting from the money. Neither GSoC nor STF binds the GA or FFmpeg to accept bad code. Have you thought about this ? where would that come from ? We send an application and a scope of work FFmpeg is no legal entity we cant sign anything binding. The developers doing the work can sign some binding text, that text might read ill implement X and get Y payed, or i spend X hours working on Y and get Z paid. If a devleoper signs "i will push this to ffmpeg" thats on the developer and her problem if it gets rejected or reverted. GSoC doesnt do this and i dont think any sane person would sign this, I myself on consulting jobs generall point out to customers that i can do work X but cannot gurantee acceptance in FFmpeg as sometimes things get rejected for hard to predict reasons. thx [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Sun, Feb 4, 2024 at 11:03 AM J. Dekker wrote: > > > On Sun, Feb 4, 2024, at 10:49, Rémi Denis-Courmont wrote: > > Hi, > > > > I don't believe it is appropriate to hold the vote before Derek's > > question is addressed. > > > > We don't really know what we're voting on here. > > > > Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis > > a écrit : > >>On 1/31/2024 9:44 PM, Derek Buitenhuis 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? > >> > >>I do not believe this has been answered. > >> > >>- Derek > > > The vote is unclear for me and also it was not explained who ‘the same > person as before’ is, no reply or answer to this either. Hope Michael can > clear this up. > > - jd > FFmpeg project is dead. > ___ > 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Sun, Feb 4, 2024, at 10:49, Rémi Denis-Courmont wrote: > Hi, > > I don't believe it is appropriate to hold the vote before Derek's > question is addressed. > > We don't really know what we're voting on here. > > Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis > a écrit : >>On 1/31/2024 9:44 PM, Derek Buitenhuis 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? >> >>I do not believe this has been answered. >> >>- Derek The vote is unclear for me and also it was not explained who ‘the same person as before’ is, no reply or answer to this either. Hope Michael can clear this up. - jd ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi, I don't believe it is appropriate to hold the vote before Derek's question is addressed. We don't really know what we're voting on here. Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis a écrit : >On 1/31/2024 9:44 PM, Derek Buitenhuis 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? > >I do not believe this has been answered. > >- Derek > >___ >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".
Re: [FFmpeg-devel] Sovereign Tech Fund
I have no relation and none of the above. There were some large items of piping that needed carrying and I did that to help my fellow human being through love of humankind. Kieran On Fri, 2 Feb 2024 at 14:52, Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 10:45:50PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, > > wrote: > > > > > On Wed, Jan 31, 2024 at 09:54:05PM +, Kieran Kunhya wrote: > > > > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > > > > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > > > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > [...] > > > > > > > This is most likely referring to the email from Thilo that an > > > anonymous > > > > > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > > > > > > > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > > > > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > > > > > > > > > - Cosmin > > > > > > > > > > > > > > > > > > > It's really not off-topic. It's about agreements that are made on > > > behalf > > > > > of > > > > > > the project without consulting the community, which is what > appears > > > to be > > > > > [...] > > > > > > We love transparency in this project, right? > > > > > > > > > > Yes, i cant awnser your questions but i have some questions myself > > > after > > > > > looking for NAB related things > > > > > > > > > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > > > > > here: > > > > > > > > > > > > > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > > > > > We can clearly see FFmpeg logo and FFmpeg text in this > > > > > > > > > > Also in the reactions, i dont recognize any except you. > > > > > > > > > > and where was that discussed with the FFmpeg community? > > > > > > > > > > Iam reading there where no FFmpeg developers on that booth just > > > buissness > > > > > people > > > > > from someone who vissited, so iam a bit confused. > > > > > > > > > > > > > Thilo was on the booth (when he felt like showing up) and j-b was on > the > > > > booth along with other Videolabs people. > > > > Julien Navas, myself and other Videolabs people built the booth in > our > > > own > > > > time free of charge. > > > > > > > > I have no idea who the " buissness people" you talk about are. > > > > > > Where did you discuss the creation of this Booth with the FFmpeg > community > > > ? > > > > > > thx > > > > > > > Ask the people who paid for it and staffed it. > > So you, for free helped to build a FFmpeg stand for the "for profit > videolabs company" > > I am a little confused here. > What is your relation to this company ? > Where you a employee, shareholder, contractor, executive of videolabs ? > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "You are 36 times more likely to die in a bathtub than at the hands of a > terrorist. Also, you are 2.5 times more likely to become a president and > 2 times more likely to become an astronaut, than to die in a terrorist > attack." -- Thoughty2 > > ___ > 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 10:45:50PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, > wrote: > > > On Wed, Jan 31, 2024 at 09:54:05PM +, Kieran Kunhya wrote: > > > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > > > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > [...] > > > > > > This is most likely referring to the email from Thilo that an > > anonymous > > > > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > > > > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > > > > > > > - Cosmin > > > > > > > > > > > > > > > > It's really not off-topic. It's about agreements that are made on > > behalf > > > > of > > > > > the project without consulting the community, which is what appears > > to be > > > > [...] > > > > > We love transparency in this project, right? > > > > > > > > Yes, i cant awnser your questions but i have some questions myself > > after > > > > looking for NAB related things > > > > > > > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > > > > here: > > > > > > > > > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > > > > We can clearly see FFmpeg logo and FFmpeg text in this > > > > > > > > Also in the reactions, i dont recognize any except you. > > > > > > > > and where was that discussed with the FFmpeg community? > > > > > > > > Iam reading there where no FFmpeg developers on that booth just > > buissness > > > > people > > > > from someone who vissited, so iam a bit confused. > > > > > > > > > > Thilo was on the booth (when he felt like showing up) and j-b was on the > > > booth along with other Videolabs people. > > > Julien Navas, myself and other Videolabs people built the booth in our > > own > > > time free of charge. > > > > > > I have no idea who the " buissness people" you talk about are. > > > > Where did you discuss the creation of this Booth with the FFmpeg community > > ? > > > > thx > > > > Ask the people who paid for it and staffed it. So you, for free helped to build a FFmpeg stand for the "for profit videolabs company" I am a little confused here. What is your relation to this company ? Where you a employee, shareholder, contractor, executive of videolabs ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Thu, Feb 01, 2024 at 06:59:14PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-02-01 00:07:02) > > > > about antons comment > > "Objections: (Anton) Coverity (and other static analysis tools) are > > notoriously prone to false positives. I am concerned that this might lead > > to a large number of patches that "fix" such false positives, but make the > > code worse." > > > > It was me years ago who brought the number of coverity issues down to > > a small number. It has exploded since. > > > > anton, where does this misstrust come from ? > > When i did all that fixing of covertiy issues long ago i closed many > > i think about 1/3 where real issues IIRC 2/3 where false positves or > > "intended" i closed the false positives and marked them accordingly as > > false or > > intended or whatever was correct. > > > > Why should i suddenly do something different ? > > I did it for 100% free back then > > and here it wouldnt even make sense, closing false positives also > > counts as resolved. Its less work even to get 70USD ;) > > What's with this hurt-feelings tone? You ASKED people to comment on the that tone happens after days of participating in some fine ff threads. You know, at day 3 you sound odd, at day 5 you wonder when you will wake up until you realize you are awake all along, on day 7 you run naked through the streets > proposals, so I asked a question. You can just answer it, no need to get > all emotional about it. I don't stalk you or your commits, why do you > expect me to know that you worked on such issues "long ago"? I don't > even know one can close coverity issues manually. > > What I do know is that I've seen similar initiatives run into this > pathology in the past, hence my question. If the person classifying is different from the person fixing issues that may reduce the incentive. Alterantively if all give the same reward that works too but theres a massive assymmetry as some issues pay way too much where others pay tpp little. it seems several people did not like that I dont think theres a perfect way thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On 1/31/2024 9:44 PM, Derek Buitenhuis 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? I do not believe this has been answered. - Derek ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Le torstaina 1. helmikuuta 2024, 19.59.14 EET Anton Khirnov a écrit : > > Why should i suddenly do something different ? > > I did it for 100% free back then > > and here it wouldnt even make sense, closing false positives also > > counts as resolved. Its less work even to get 70USD ;) > > What's with this hurt-feelings tone? You ASKED people to comment on the > proposals, so I asked a question. You can just answer it, no need to get > all emotional about it. I don't stalk you or your commits, why do you > expect me to know that you worked on such issues "long ago"? I don't > even know one can close coverity issues manually. > > What I do know is that I've seen similar initiatives run into this > pathology in the past, hence my question. Yeah, well there are two sides to this issue. The obvious one is that it reviewing code takes time and is not exactly the most rewarding job. This is especially true for reviewing dull issues like Coverity's, but it is generally true. The lesser obvious flip-side is that somebody should also review the handling of Coverity issues, even those that end up marked as "False positive" or "Intentional". This gets even worse if everybody knows that someone else is paid. Then the incentive to review on one's free time gets even lower in my experience. I don't know how to address that paradox generally speaking, but I do think that bug triaging, bug fixing and code review should be paid per hour, not per bug report (and I count Coverity issues as a type of bug reports). This is not just theoretical. I have actually previously worked in an organisation that paid contractors per bug as a unit, and of course people gamed the system to get paid more with little extra work. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Michael Niedermayer (2024-02-01 00:07:02) > > about antons comment > "Objections: (Anton) Coverity (and other static analysis tools) are > notoriously prone to false positives. I am concerned that this might lead to > a large number of patches that "fix" such false positives, but make the code > worse." > > It was me years ago who brought the number of coverity issues down to > a small number. It has exploded since. > > anton, where does this misstrust come from ? > When i did all that fixing of covertiy issues long ago i closed many > i think about 1/3 where real issues IIRC 2/3 where false positves or > "intended" i closed the false positives and marked them accordingly as false > or > intended or whatever was correct. > > Why should i suddenly do something different ? > I did it for 100% free back then > and here it wouldnt even make sense, closing false positives also > counts as resolved. Its less work even to get 70USD ;) What's with this hurt-feelings tone? You ASKED people to comment on the proposals, so I asked a question. You can just answer it, no need to get all emotional about it. I don't stalk you or your commits, why do you expect me to know that you worked on such issues "long ago"? I don't even know one can close coverity issues manually. What I do know is that I've seen similar initiatives run into this pathology in the past, hence my question. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On date Thursday 2024-02-01 00:15:03 +0100, Stefano Sabatini wrote: > José already provided and excellent summary from his side. On my side I meant Jonatas, sorry. ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On date Wednesday 2024-01-31 18:10:57 +0200, Rémi Denis-Courmont wrote: > Hi, [...] > Sarcasm aside, I take that to mean that SPI has been involved with those > discussions for months in a private and closed process. Michael asserted that > an open inclusive process is better than the usual closed approach whence the > funding goes through a company. > > It looks to me that those SPI discussions were just as opaque and closed, and > all the talk of openess is just pretense. It does not help that Michael, and > now you too, misrepresent any challenge to SPI proposed *process* as an > attempt to reject the idea of STF sponsorship, under the convenient pretext > that there is not enough time. > > This is further aggravated by the context that Michael brought forward the > idea of funding developers through SPI 3 months ago (in actual Earth units). > From your statement, I have to infer that Thilo, Michael and SPI already knew > of the STF plan and concealed that key piece of contextual information back > then. > José already provided and excellent summary from his side. On my side I can say I was involved in the discussion, and that this was mostly about the feasibility and the groundwork of approaching STF and later SPI. So in my opinion there was no need to involve the community at that early stage, especially given that until the past week there was still no evidence that STF was providing a grant (and BTW, still this needs to be substantiated with a SOW and then it will have to be reviewed and approved on the STF side). Also SPI was involved at a later stage, after the investigation about using the donors fund for active development (which also involves the handling of SOW from SPI to the individual contributor). The main result of that investigation was discussed in the open and can be found here: https://ffmpeg.org/pipermail/ffmpeg-devel/2023-October/315702.html If I undestand it correctly, it was never committed because there was a disagreement about where to put it (ffmpeg or ffmpeg-web) and about the general intent, then at some point the discussion died off before a conclusion was really reached. Note that the focus in that case was to make good use of the donations fund (keeping it in the account is not a good use for it). > In hindsight, it feels hypocritical to me that they were arguing for the SPI > path, and against the corporate path, on the basis of openess already then, > to > be honest. > > I can only agree with Anton that this looks like an attempt to strongarm the > community. This is ostensibly being to ignore all the objections that were > already brought in October and are being brought again now, with the > complicity of SPI. I can't say that this looks well on SPI, but that's just > my > personal opinion. SPI was involved at a later stage to act as fiscal sponsor for STF. Just to reiterate, SPI involvement was requested, and was not actively seeked by SPI itself. I cannot read any attempt to strongarm the community, nor I see why this should challenge the corporate path (which has a different focus and has its own merits). > With all that said, I don't think anybody will attempt to prevent this from > happening (if they even can?). But that will take place without the consent > of > the GA, without any legitimacy on the claims of openess and inclusiveness, > and > obviously without any form of preclearance from the technical appropriateness > of the resulting code contributions. It's unfortunate there is a tight deadline - one option would be to try to delay the deadline and ask General Assembly for a vote before the application is sent - we might probably want both things to avoid the feeling that this is done against the "community" and create a tense environment, but any of this might probably result in voiding the opportunity. Also, it should be assumed that this proposal was done in good faith, in view of the sustainability discussions done in the past months. ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis > 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. you forgot to add yourself with a lower price its weak to claim something expensive (which is true) but not willing to do the work at a lower price about antons comment "Objections: (Anton) Coverity (and other static analysis tools) are notoriously prone to false positives. I am concerned that this might lead to a large number of patches that "fix" such false positives, but make the code worse." It was me years ago who brought the number of coverity issues down to a small number. It has exploded since. anton, where does this misstrust come from ? When i did all that fixing of covertiy issues long ago i closed many i think about 1/3 where real issues IIRC 2/3 where false positves or "intended" i closed the false positives and marked them accordingly as false or intended or whatever was correct. Why should i suddenly do something different ? I did it for 100% free back then and here it wouldnt even make sense, closing false positives also counts as resolved. Its less work even to get 70USD ;) and about the 70 USD. Its a point at which i hoped someone else would add himself, apparently its enough someone complains but noone wants to do it still. hmm and about 1min, the average time it takes to analyze issues is definitly going to be above this unless the issues look very different than previosuly though also you will surely find a dozen similar ones where you can close each in 5sec. on average 30min per issues with all analysis, double checking documentation 1/3 of the time writing a patch, testing and submitting is more real. So you could make 140USD per hour IMHO at 70USD per issue I think thats realistic unless the issues are different now than years ago (the 30min estimate includes a saftey factor which one has to include for this kind of work) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, wrote: > On Wed, Jan 31, 2024 at 09:54:05PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > > > ffmpeg-devel@ffmpeg.org> wrote: > > > [...] > > > > > This is most likely referring to the email from Thilo that an > anonymous > > > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > > > > > - Cosmin > > > > > > > > > > > > > It's really not off-topic. It's about agreements that are made on > behalf > > > of > > > > the project without consulting the community, which is what appears > to be > > > [...] > > > > We love transparency in this project, right? > > > > > > Yes, i cant awnser your questions but i have some questions myself > after > > > looking for NAB related things > > > > > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > > > here: > > > > > > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > > > We can clearly see FFmpeg logo and FFmpeg text in this > > > > > > Also in the reactions, i dont recognize any except you. > > > > > > and where was that discussed with the FFmpeg community? > > > > > > Iam reading there where no FFmpeg developers on that booth just > buissness > > > people > > > from someone who vissited, so iam a bit confused. > > > > > > > Thilo was on the booth (when he felt like showing up) and j-b was on the > > booth along with other Videolabs people. > > Julien Navas, myself and other Videolabs people built the booth in our > own > > time free of charge. > > > > I have no idea who the " buissness people" you talk about are. > > Where did you discuss the creation of this Booth with the FFmpeg community > ? > > thx > Ask the people who paid for it and staffed it. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 09:54:05PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer > wrote: > > > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > > ffmpeg-devel@ffmpeg.org> wrote: > > [...] > > > > This is most likely referring to the email from Thilo that an anonymous > > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > > > - Cosmin > > > > > > > > > > It's really not off-topic. It's about agreements that are made on behalf > > of > > > the project without consulting the community, which is what appears to be > > [...] > > > We love transparency in this project, right? > > > > Yes, i cant awnser your questions but i have some questions myself after > > looking for NAB related things > > > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > > here: > > > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > > We can clearly see FFmpeg logo and FFmpeg text in this > > > > Also in the reactions, i dont recognize any except you. > > > > and where was that discussed with the FFmpeg community? > > > > Iam reading there where no FFmpeg developers on that booth just buissness > > people > > from someone who vissited, so iam a bit confused. > > > > Thilo was on the booth (when he felt like showing up) and j-b was on the > booth along with other Videolabs people. > Julien Navas, myself and other Videolabs people built the booth in our own > time free of charge. > > I have no idea who the " buissness people" you talk about are. Where did you discuss the creation of this Booth with the FFmpeg community ? 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 signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis 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. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > [...] > > > This is most likely referring to the email from Thilo that an anonymous > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > - Cosmin > > > > > > > It's really not off-topic. It's about agreements that are made on behalf > of > > the project without consulting the community, which is what appears to be > [...] > > We love transparency in this project, right? > > Yes, i cant awnser your questions but i have some questions myself after > looking for NAB related things > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > here: > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > We can clearly see FFmpeg logo and FFmpeg text in this > > Also in the reactions, i dont recognize any except you. > > and where was that discussed with the FFmpeg community? > > Iam reading there where no FFmpeg developers on that booth just buissness > people > from someone who vissited, so iam a bit confused. > Thilo was on the booth (when he felt like showing up) and j-b was on the booth along with other Videolabs people. Julien Navas, myself and other Videolabs people built the booth in our own time free of charge. I have no idea who the " buissness people" you talk about are. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
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 ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: [...] > > This is most likely referring to the email from Thilo that an anonymous > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > Seems off-topic for this thread about SPI and STF. > > > > - Cosmin > > > > It's really not off-topic. It's about agreements that are made on behalf of > the project without consulting the community, which is what appears to be [...] > We love transparency in this project, right? Yes, i cant awnser your questions but i have some questions myself after looking for NAB related things who did the 2023 booth on NAB for FFmpeg (W3323) ? here: https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ We can clearly see FFmpeg logo and FFmpeg text in this Also in the reactions, i dont recognize any except you. and where was that discussed with the FFmpeg community? Iam reading there where no FFmpeg developers on that booth just buissness people from someone who vissited, so iam a bit confused. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On date Wednesday 2024-01-31 13:30:50 +0100, Anton Khirnov wrote: > Quoting Stefano Sabatini (2024-01-30 00:53:25) > > On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: [...] > > > 1) How does the project protect itself from pre-approving some code that > > >does not exist yet? This is not just some theoretical danger, it's > > >easily possible that some project sounds good in theory, but actually > > >implementing it comes with so many gotchas and caveats that it ends > > >up being not worth it. Or there are fundamental technical > > >disagreements about the specific way it's been implemented. Both > > >cases exist in our history. > > > > The design and investigative work should be covered as part of the > > SOW. In other words, the SOW should also cover the preliminary design > > and experimentation. In case it leads to no committable work (which is > > unlikely but not impossible), the output should be a document/report > > documenting the result of the initial investigation, and the project > > might be aborted at that point. > > > > This should protect both the developer and the project. In each case > > it should be assumed that the final result of the investigation would > > not lead to committable deliverables, but to design documents which > > might lay the foundation of further work (possibly in a different > > direction). > > That might be a viable direction, but it does not really solve the > problem. Initial investigation only gets you so far and some issues > simply do not become apparent until quite far in the development > process. > > E.g. my recent threading work (that keeps getting mentioned in this > thread as an example of what a cleanup project could look like) was > largely composed of many "sub-projects", each disentangling a specific > feature or area. And there was no reliable way to predict in advance > whether a given sub-project would take two hours or two weeks. So let's tweak the format. It might be formulated as something as: --8< This project covers doing this and that. It will be split in several stages lasting a given amount of time (e.g. two months per each stage). At the end of each stage the developer will provide a report giving an overview of the findings and of delivered code, which will be the subject of the invoice. --8< In this way we drop the requirement on achieving a specific goal in terms of committed code, and require instead a report to document the changes/finding (which will be subject to validation). Maybe José can provide some guidance about the viability of this specific format. Assuming this format is acceptable on the STF/SPI side, the next problem is to understand who is going to provide the validation based on the report. The SPI liaison might be involved but only to sign-off, not to provide the actual validation, which must be agreed upon by the project according to some agreed internal procedures. Other issues might arise in case the work is delayed due to various circumstances (e.g. the developer getting sick or having other external impediments or having more urgent tasks to attend). In this case I can foresee a few possible outcomes: the developer will delay sending the invoice, or the invoiced sum is reduced accordingly. It seems to me we need to design these validation processes in advance or we risk to turn each invoice delivery into a potential flamefest. ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > > > On Jan 31, 2024, at 11:07 AM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer < > mich...@niedermayer.cc> > >> wrote: > >> > >>> Hi Jonatas, Remi > >>> > >>> _THIS_ reply shows why i LOVE SPI > >>> > >>> I mean this is transparency, anyone try to get something similar from a > >>> corporation > >>> > >>> Just in the last 48h i have seen a reminder from a CEO about > "shareholder > >>> agreement" > >>> and privacy > >>> > >> > >> If you want transparency, where is the agreement between SPI and STF? > > > >> Where > >> is the agreement for the NAB booth? > > > > I did search my inbox and spam folder fro NAB but nothing looked related > to a booth agreement. > > I have someoen trying to sell me an "Attendees Database" for NAB since > 2018 though > > and lots of can nab is spam. > > > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > > > > This is most likely referring to the email from Thilo that an anonymous > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > Seems off-topic for this thread about SPI and STF. > > - Cosmin > It's really not off-topic. It's about agreements that are made on behalf of the project without consulting the community, which is what appears to be happening between SPI and STF as well. There is currently a booth registered under the FFmpeg name: https://nab24.mapyourshow.com/8_0/exhview/?hallID=W=W4232 Currently it has the following address associated to FFmpeg: Bergemannweg 20 Berlin 13503 Germany Who does this address belong to? Who will be paying the construction costs, graphics, furniture costs, etc for this booth? Who will be staffing the booth? Derek and I have asked this question several times now and received no response. We love transparency in this project, right? Regards, Kieran Kunhya Sent from my mobile device ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
I can't find anything in SPI related to NAB either. I can ask the officers if they're aware of something from NAB, but I don't think that would be the case. I can find some old booths for FOSSEM, FOSDEM and whatnot though. Can you double check? (Also: What's the relation between NAB and this sponsorship?) Regards, Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 16:07 Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > Hi Jonatas, Remi > > > > > > _THIS_ reply shows why i LOVE SPI > > > > > > I mean this is transparency, anyone try to get something similar from a > > > corporation > > > > > > Just in the last 48h i have seen a reminder from a CEO about > "shareholder > > > agreement" > > > and privacy > > > > > > > If you want transparency, where is the agreement between SPI and STF? > > > Where > > is the agreement for the NAB booth? > > I did search my inbox and spam folder fro NAB but nothing looked related > to a booth agreement. > I have someoen trying to sell me an "Attendees Database" for NAB since > 2018 though > and lots of can nab is spam. > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> On Jan 31, 2024, at 11:07 AM, Michael Niedermayer > wrote: > > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer >> wrote: >> >>> Hi Jonatas, Remi >>> >>> _THIS_ reply shows why i LOVE SPI >>> >>> I mean this is transparency, anyone try to get something similar from a >>> corporation >>> >>> Just in the last 48h i have seen a reminder from a CEO about "shareholder >>> agreement" >>> and privacy >>> >> >> If you want transparency, where is the agreement between SPI and STF? > >> Where >> is the agreement for the NAB booth? > > I did search my inbox and spam folder fro NAB but nothing looked related to a > booth agreement. > I have someoen trying to sell me an "Attendees Database" for NAB since 2018 > though > and lots of can nab is spam. > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > This is most likely referring to the email from Thilo that an anonymous corporate sponsor is providing ffmpeg with a booth at NAB 2024 https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html Seems off-topic for this thread about SPI and STF. - 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer > wrote: > > > Hi Jonatas, Remi > > > > _THIS_ reply shows why i LOVE SPI > > > > I mean this is transparency, anyone try to get something similar from a > > corporation > > > > Just in the last 48h i have seen a reminder from a CEO about "shareholder > > agreement" > > and privacy > > > > If you want transparency, where is the agreement between SPI and STF? > Where > is the agreement for the NAB booth? I did search my inbox and spam folder fro NAB but nothing looked related to a booth agreement. I have someoen trying to sell me an "Attendees Database" for NAB since 2018 though and lots of can nab is spam. So either i searched for the wrong term or i was not CC-ed on such an agreement thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 18:40, Jonatas L. Nogueira wrote: > I assume you don't mean National Association of Broadcasters by "NAB", so > I would need to know what booth you're talking about. > That is what I mean. Kieran > On Wed, Jan 31, 2024 at 3:22 PM Kieran Kunhya wrote: > >> >> >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer >> wrote: >> >>> Hi Jonatas, Remi >>> >>> _THIS_ reply shows why i LOVE SPI >>> >>> I mean this is transparency, anyone try to get something similar from a >>> corporation >>> >>> Just in the last 48h i have seen a reminder from a CEO about >>> "shareholder agreement" >>> and privacy >>> >> >> If you want transparency, where is the agreement between SPI and STF? >> Where is the agreement for the NAB booth? >> >> Kieran >> >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
There are no agreements between SPI and STF as of 31st January 2024. However, if you submit a Scope of Work, then an agreement will be made if STF approves the sponsorship (on the Feb 14th or later). I assume you don't mean National Association of Broadcasters by "NAB", so I would need to know what booth you're talking about. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 3:22 PM Kieran Kunhya wrote: > > > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer > wrote: > >> Hi Jonatas, Remi >> >> _THIS_ reply shows why i LOVE SPI >> >> I mean this is transparency, anyone try to get something similar from a >> corporation >> >> Just in the last 48h i have seen a reminder from a CEO about "shareholder >> agreement" >> and privacy >> > > If you want transparency, where is the agreement between SPI and STF? > Where is the agreement for the NAB booth? > > Kieran > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer wrote: > Hi Jonatas, Remi > > _THIS_ reply shows why i LOVE SPI > > I mean this is transparency, anyone try to get something similar from a > corporation > > Just in the last 48h i have seen a reminder from a CEO about "shareholder > agreement" > and privacy > If you want transparency, where is the agreement between SPI and STF? Where is the agreement for the NAB booth? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Jonatas, Remi _THIS_ reply shows why i LOVE SPI I mean this is transparency, anyone try to get something similar from a corporation Just in the last 48h i have seen a reminder from a CEO about "shareholder agreement" and privacy thx On Wed, Jan 31, 2024 at 05:04:20PM +, Jonatas L. Nogueira via ffmpeg-devel wrote: [...] -- 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. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Rémi On Wed, Jan 31, 2024 at 06:10:57PM +0200, Rémi Denis-Courmont wrote: [...] > This is further aggravated by the context that Michael brought forward the > idea of funding developers through SPI 3 months ago (in actual Earth units). > From your statement, I have to infer that Thilo, Michael and SPI already knew > of the STF plan and concealed that key piece of contextual information back > then. Iam evil I had talked with ronald and heared about the "sustainability" "need" and from that made several plans. One i posted and was flamed because it sounded similar to a talk on demuxed. (I think using the word "sustainability") One of the other ideas was indeed STF: look: -rw-r- 1 michael michael 666 Okt 26 11:39 sustainability-consulting.txt -rw-r- 1 michael michael 666 Okt 26 11:39 sustainability-consulting.txt~ -rw-r- 1 michael michael 2604 Dez 27 00:13 sustainability-license.txt -rw-r- 1 michael michael 2504 Dez 27 00:13 sustainability-license.txt~ -rw-r- 1 michael michael 801 Nov 15 09:47 sustainability-notes2.txt -rw-r- 1 michael michael 801 Nov 15 09:47 sustainability-notes2.txt~ -rw-r- 1 michael michael 319 Okt 26 11:49 sustainability-other.txt -rw-r- 1 michael michael 319 Okt 26 11:49 sustainability-other.txt~ -rw-r- 1 michael michael 1828 Okt 26 13:46 sustainability-spi.txt -rw-r- 1 michael michael 1828 Okt 26 13:46 sustainability-spi.txt~ -rw-r- 1 michael michael 9812 Jan 12 23:45 sustainability-stf.txt -rw-r- 1 michael michael 7450 Jan 12 23:45 sustainability-stf.txt~ I did intend to leave some time between posting each idea so people could reload their guns properly but as life goes things get delayed, one is busy and also in the STF case there was some push towards waiting several of these ideas i still had no time to properly spell out and post Also just because i wrote something doesnt mean these are finished, presentable ideas All that said, its not entirely uncommon that people publically hear of things months after someone knew of something about it. You can compare this to the bloomberg donation and the open collective account that was created for ffmpeg by jb: https://opencollective.com/ffmpeg There was no public question before that account was created, I know because some people where privatly upset about that. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> I take that to mean that SPI has been involved with those discussions for months in a private and closed process Not really, however STF did ask for a meeting with SPI concerning the possibility to sponsor FFmpeg on January 18th (so roughly two weeks ago). To make clear, the request was on the 15th, the actual meeting on the 18th. There was some back-and-forth between both, Thilo and Michael commented on some specifics as STF or SPI asked, and we concluded SPI could indeed receive a sponsorship from STF on behalf of FFmpeg project on January 23th. Not long after, STF confirmed to SPI that it would be discussed in Feb 14th internally and that FFmpeg should send a Scope of Work by the 12th in order to confirm the sponsorship. That request was sent on Jan 25th. I'm not sure when this information was sent to this mailing list, but Michael and Thilo were informed on the same day. That's what happened recently on the SPI side in any Earthly time metric. But I should mention that in July 2023, Stefano and our contractors reached out to me and the vice president asking for, among other things, the Master Service Agreement which SPI uses and some general and everyday discussions about SPI policies regarding the payment of individual contractors/developers. I believe they also mentioned the possibility of getting a sponsorship from STF in the future, but discussions were centered on how SPI could pay for individual developers, which is why I didn't remember about this until I searched for it today. I guess you could say SPI was "aware" of the possibility since then. The first and last message from this message chain were on July 11th and July 23rd respectively, although I assume they made questions to non-board members before reaching out for SPI's VP and me. There was no further contact with SPI about that between July 24th and January 15th. Miscommunication happens. Do not assume malice, if you need any further information from SPI just reach out, we'll be happy to provide. > misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time. Just in case, it was STF who asked for a Scope of Work to be presented by February 12th. I'm pretty sure it is possible to ask them about the possibility of postponing the topic for their next meeting (which I assume to be in March) ─ STF may decline, though, and it might not be possible to turn back on this decision or postpone further. I'm not STF's contact, it is someone from FFmpeg who is, so they'll need to do this. (also why I didn't mention that earlier). SPI is not conducting these discussions, after all. That's something you have to decide by yourselves. > This is ostensibly being to ignore all the objections that were already brought in October [...] SPI is not aware of any such objections. > But that will take place without the consent of the GA I'm not sure SPI would accept the sponsorship from STF without the consent of the GA, although we do expect to hear from Stefano the position FFmpeg is going to take. Which does mean that if STF sends funds to SPI but Stefano says he doesn't know what they're about, SPI will return the money post-haste (and will be less willing to receive potentially unwanted money later, as returning funds is not without costs). > I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then. SPI usually doesn't *do* anything until it is asked to. We were aware in July 2023 that FFmpeg was considering asking STF about a sponsorship, although we weren't informed of whatever happened until STF asked for a meeting with us on January 15th. (Some of the SPI Board members even presumed FFmpeg had given up and forgotten altogether). > I can only agree with Anton that this looks like an attempt to strongarm the community. SPI is not trying to strongarm you into anything. Unless you try to do something illegal and we're required by law to intervene, I guess, which was discussed (e.g. "can the GA refuse to pay an invoice which is due?", which I made clear SPI would pay the invoice despite the objection, because the law requires it to be done). SPI as a rule of thumb does not interfere in its projects' management and decisions. If you want to give up on the sponsorship we'll honor the decision, if you want the sponsorship in different terms we can discuss if it's possible (and if it's not, SPI will not accept, because as I said earlier SPI is bound by the law). And if you want for more time to discuss, you should be asking that to STF, I can only help you as an agenda UNDER THE PRETENSE that FFmpeg is actually interested in meeting with STF request. If FFmpeg is not interested in attending STF's request of delivering them a Scope of Work by February 12th, I'll stop posting agenda-like reminders or suggestions. Att., -- Jonatas L. Nogueira (“jesusalva”)
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi, Le keskiviikkona 31. tammikuuta 2024, 16.10.02 EET Jonatas L. Nogueira via ffmpeg-devel a écrit : > > IMO hasty actions and avoidable drama may cause damage to the project > > What would be a hasty action? I've seen far too much people calling action > over stuff discussed for weeks/months as "hasty" in attempt to stall into > endless discussions, so you might want to clarify. Would you care to clarify which astronomical body do you count weeks and months in? I believe that it is customary to use Earth units when you do not specify. And in this case, the topic was brought to the community just about 0.5 week, or 0.11 month ago. Sarcasm aside, I take that to mean that SPI has been involved with those discussions for months in a private and closed process. Michael asserted that an open inclusive process is better than the usual closed approach whence the funding goes through a company. It looks to me that those SPI discussions were just as opaque and closed, and all the talk of openess is just pretense. It does not help that Michael, and now you too, misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time. This is further aggravated by the context that Michael brought forward the idea of funding developers through SPI 3 months ago (in actual Earth units). From your statement, I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then. In hindsight, it feels hypocritical to me that they were arguing for the SPI path, and against the corporate path, on the basis of openess already then, to be honest. I can only agree with Anton that this looks like an attempt to strongarm the community. This is ostensibly being to ignore all the objections that were already brought in October and are being brought again now, with the complicity of SPI. I can't say that this looks well on SPI, but that's just my personal opinion. With all that said, I don't think anybody will attempt to prevent this from happening (if they even can?). But that will take place without the consent of the GA, without any legitimacy on the claims of openess and inclusiveness, and obviously without any form of preclearance from the technical appropriateness of the resulting code contributions. -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Forgot to mention, but you also don't need to set the values yourself. You can simply post "we're looking to have X task done, interested parties please send us a quote" and see if it fits the budget. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 1:00 PM Jonatas L. Nogueira wrote: > > The FFmpeg community was told about this three days ago. > > Fair enough if it's true (I'm an outsider, after all) > > > There are arguments in this very thread how we cannot discuss things in > > detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this > > makes the mood more tense, especially given the other circumstances. > > What I noticed (as an external observator), was putting the cart ahead of > the horse. There's no money right now, but STF is willing to grant around > 200k if FFmpeg is able to submit a Scope of Work in time for their meeting > (happening on Feb 14th, materials however should be submitted 48 hours > before). The scope of work is, in other words, a letter of intentions of > what to do with such money. They have already informed about the > restrictions (e.g. should be maintenance or security related, that it is > too early to ask for feature projects but it might be possible in the > future, etc). > > A Scope of Work is a bit more than a wishlist because it assumes the work > is actually going to be done, so it cannot be too overambitious. That's > what needs to "act now or all the money is gone". The question currently > presented is, "if FFmpeg had 200k euros to work with maintenance, what > would FFmpeg do?" ─ this will become the Scope of Work (we can have people > to word it into legalese later, if needed). > > Of course, all that will end in a Statement of Work (SOW) later, > describing how the wishlist in the Scope of Work will be attained as > everyone knows that money doesn't magically solve problems. And from what > I've seen as an external observer, there is a lot of discussion pending for > this. But that's alright, there's probably over a month for that. Of > course, without a Scope of Work, there'll be no SOW, and any discussion > made on this will become a waste of time. > > If I were the one doing it... I would first make a wishlist in a shared > document with all tasks eligible (3~5 days, so completion until Feb 5th > latest). There are time constraints, though, and FFmpeg takes decisions > collectively, so... I would make a vote between Feb 5th and Feb 12th (yes, > the deadline) to elect the tasks which will be on the Scope of Work. I > would improvise a bit: ask the submitted tasks to also have a proponent > (who is asking for the task to be done) and a budget (how much money the > proponent thinks that will be enough to attain it). The budget here is > nonsense, it is just to have a metric to decide how many options will go to > the Scope of Work. The proponent is to answer questions the voters may have. > > With that laid out and once in motion, the remainder of discussion would > be held. How much to pay the contributors, the actual budget for the > approved projects, how it'll be tracked, what's more fair for deliverables, > how they'll be checked, if you'll contract the developers directly or with > an intermediary, etc. There's no point discussing any of that unless you're > sure the scope of work can be delivered in time. Multiple Statements of > Work are also possible, so there's no actual need for one-size-fits-all in > those questions. If project A, B and C can be divided into commits but > project D cannot, it's fine to have different rules for project D. Also why > it doesn't make much sense to hold these discussions now, when you can't > even answer what would be the projects. > > That, however, is not my call. I can provide suggestions, but actually > coming with a Scope of Work in time is yours and yours alone. > > > So far it does not seem we have an abundance of volunteers, so it seems > > more likely we'll struggle to spend all the money. > > Coincidentally, that happens a lot. No reason to let it hinder you, > though, having money gives the option to make job postings, and you might > even be able to ask for help in spi-general list. > > > only a minority of time is spent typing code. > > Don't I know it... I'm also a programmer for The Mana World, pretty > familiar with "I changed a couple lines and now nothing works, spend two > hours trying to figure out that I forgot a curly brace". > > That is among the discussions I believe FFmpeg should have, although you > might want to have the Scope of Work rolling before starting this. (And > there are many possible solutions, so I expect quite some time to be spent > finding all of them and picking out the best one). > > If you start discussing how to properly pay for the hours spent hunting > simple typo mistakes now, you'll never be able to tell STF what actually > needs to be done in time. > > -- > Jonatas L.
Re: [FFmpeg-devel] Sovereign Tech Fund
> The FFmpeg community was told about this three days ago. Fair enough if it's true (I'm an outsider, after all) > There are arguments in this very thread how we cannot discuss things in > detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this > makes the mood more tense, especially given the other circumstances. What I noticed (as an external observator), was putting the cart ahead of the horse. There's no money right now, but STF is willing to grant around 200k if FFmpeg is able to submit a Scope of Work in time for their meeting (happening on Feb 14th, materials however should be submitted 48 hours before). The scope of work is, in other words, a letter of intentions of what to do with such money. They have already informed about the restrictions (e.g. should be maintenance or security related, that it is too early to ask for feature projects but it might be possible in the future, etc). A Scope of Work is a bit more than a wishlist because it assumes the work is actually going to be done, so it cannot be too overambitious. That's what needs to "act now or all the money is gone". The question currently presented is, "if FFmpeg had 200k euros to work with maintenance, what would FFmpeg do?" ─ this will become the Scope of Work (we can have people to word it into legalese later, if needed). Of course, all that will end in a Statement of Work (SOW) later, describing how the wishlist in the Scope of Work will be attained as everyone knows that money doesn't magically solve problems. And from what I've seen as an external observer, there is a lot of discussion pending for this. But that's alright, there's probably over a month for that. Of course, without a Scope of Work, there'll be no SOW, and any discussion made on this will become a waste of time. If I were the one doing it... I would first make a wishlist in a shared document with all tasks eligible (3~5 days, so completion until Feb 5th latest). There are time constraints, though, and FFmpeg takes decisions collectively, so... I would make a vote between Feb 5th and Feb 12th (yes, the deadline) to elect the tasks which will be on the Scope of Work. I would improvise a bit: ask the submitted tasks to also have a proponent (who is asking for the task to be done) and a budget (how much money the proponent thinks that will be enough to attain it). The budget here is nonsense, it is just to have a metric to decide how many options will go to the Scope of Work. The proponent is to answer questions the voters may have. With that laid out and once in motion, the remainder of discussion would be held. How much to pay the contributors, the actual budget for the approved projects, how it'll be tracked, what's more fair for deliverables, how they'll be checked, if you'll contract the developers directly or with an intermediary, etc. There's no point discussing any of that unless you're sure the scope of work can be delivered in time. Multiple Statements of Work are also possible, so there's no actual need for one-size-fits-all in those questions. If project A, B and C can be divided into commits but project D cannot, it's fine to have different rules for project D. Also why it doesn't make much sense to hold these discussions now, when you can't even answer what would be the projects. That, however, is not my call. I can provide suggestions, but actually coming with a Scope of Work in time is yours and yours alone. > So far it does not seem we have an abundance of volunteers, so it seems > more likely we'll struggle to spend all the money. Coincidentally, that happens a lot. No reason to let it hinder you, though, having money gives the option to make job postings, and you might even be able to ask for help in spi-general list. > only a minority of time is spent typing code. Don't I know it... I'm also a programmer for The Mana World, pretty familiar with "I changed a couple lines and now nothing works, spend two hours trying to figure out that I forgot a curly brace". That is among the discussions I believe FFmpeg should have, although you might want to have the Scope of Work rolling before starting this. (And there are many possible solutions, so I expect quite some time to be spent finding all of them and picking out the best one). If you start discussing how to properly pay for the hours spent hunting simple typo mistakes now, you'll never be able to tell STF what actually needs to be done in time. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 12:17 PM Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > >> > IMO hasty actions and avoidable drama may cause damage to the project >> >> What would be a hasty action? I've seen far too much people calling action >> over stuff discussed for weeks/months as "hasty" in attempt to stall into >> endless discussions, so you might
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > IMO hasty actions and avoidable drama may cause damage to the project > > What would be a hasty action? I've seen far too much people calling action > over stuff discussed for weeks/months as "hasty" in attempt to stall into > endless discussions, so you might want to clarify. > The FFmpeg community was told about this three days ago. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Jonatas L. Nogueira via ffmpeg-devel (2024-01-31 15:10:02) > > IMO hasty actions and avoidable drama may cause damage to the project > > What would be a hasty action? I've seen far too much people calling action > over stuff discussed for weeks/months as "hasty" in attempt to stall into > endless discussions, so you might want to clarify. There are arguments in this very thread how we cannot discuss things in detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this makes the mood more tense, especially given the other circumstances. > > The question is, what exactly would be the reprecussion for failing to > achieve projects. To us? To SPI? Not to mention the developer not > getting paid. > > Given the current goal is to fund continuous maintenance tasks, it'll only > be a large problem with unpaid people if final state isn't better than > initial (eg. code gets more bloated instead of less). Otherwise, even if > some specific task cannot be completed, that's not an issue by itself, the > time already spent can be paid, as long that there's something to show for > it. (That's also an issue, but thankfully a debate for later). > > Of course, if everything ends up unfinished that'll only scream you're > terrible at planning or outright don't know what you're doing. > Repercussions could make harder for you to acquire funds in the future and > likely comments that SPI should follow its projects more closely. > > So mixing some easy but boring tasks is definitely a good idea. > > > So you're basically saying the developers have to take the risk onto > themselves > > Could you explain what exactly the risk devs are taking is? I can help if > you can make the usual risk assessment table (what risk, likelihood, and > impact/consequence). The risk for the developers is spending a lot of time and not getting paid accordingly. I see the danger of that happening when the project depends on the delivery of some specific milestone, which * is never reached because of disagreements during review * turns out to require significantly more effort than it was budgeted for The only proposed way of avoiding these is for every project to be either: * Decomposable into very small discrete tasks, which is doable only in some cases. * Of the form 'work towards X', but then evaluation becomes more tricky. > > it's widely acknowledged that > accurate time estimates for complex projects are somewhere between > extremely hard and unfeasible. > > I don't think a year is a question of accuracy, it usually indicates that > the code is becoming lasagna (if no result can be provided), ravioli (if > result can be provided but it doesn't work) or spaghetti (when it can be > provided and works... sometimes). > > That sounds exactly like a good use for a maintenance grant, identifying > where the existing code base is problematic and trying to tidy it up. > That's also not something you can say "will be done by X", it's just > something you pour hours and hope end result is easier to work with than > the previous state (even if it's still pasta). > > That's why the Scope of Work (which is the current task) for this is less > concerned in end results or deadlines, but in goals which can be attained > within a time frame (even if they're "making better" or can only be partly > attained, which would cause STF to believe you to be overambitious but is > not as problematic as not attaining anything at all). > > > developers will try to protect themselves by playing it safe > and budgeting for the largest amount of time they think they might > possibly need. Which means in most cases they will need less time, > sometimes significantly less. Would STF be okay with us being so > wasteful? > > No one is going to get paid according to their budget, the payment is over > how much time they actually spent. Budget is a limit, so the developer has > a good idea since the start of how long they can take. If they notice it'll > go over budget, they can stop, reevaluate and propose new budgets or > partial deliveries (or whatever the GA/STF decides to be acceptable). More > often than not, they'll have run in an unforeseen issue which could warrant > a fund/budget on its own. > > So if you budget 15 hours and work 5, you'll be paid for 5 and the surplus > of 10 hours can be given to other projects or assigned somewhere nearing > over budgeting so it can be finished (or at least, delivered). So far it does not seem we have an abundance of volunteers, so it seems more likely we'll struggle to spend all the money. > > my main point is that the amount of work to be done on any > interesting cleanup is unknowable beforehand. That means you have to > budget for the worst case, which means in the median case you will be > significantly overpaid. > > I agree it's impossible to know, and I am sure STF is aware of that as > well. That's also why particulars usually don't fund these things, but > public funds like STF
Re: [FFmpeg-devel] Sovereign Tech Fund
> IMO hasty actions and avoidable drama may cause damage to the project What would be a hasty action? I've seen far too much people calling action over stuff discussed for weeks/months as "hasty" in attempt to stall into endless discussions, so you might want to clarify. > The question is, what exactly would be the reprecussion for failing to achieve projects. To us? To SPI? Not to mention the developer not getting paid. Given the current goal is to fund continuous maintenance tasks, it'll only be a large problem with unpaid people if final state isn't better than initial (eg. code gets more bloated instead of less). Otherwise, even if some specific task cannot be completed, that's not an issue by itself, the time already spent can be paid, as long that there's something to show for it. (That's also an issue, but thankfully a debate for later). Of course, if everything ends up unfinished that'll only scream you're terrible at planning or outright don't know what you're doing. Repercussions could make harder for you to acquire funds in the future and likely comments that SPI should follow its projects more closely. So mixing some easy but boring tasks is definitely a good idea. > So you're basically saying the developers have to take the risk onto themselves Could you explain what exactly the risk devs are taking is? I can help if you can make the usual risk assessment table (what risk, likelihood, and impact/consequence). > it's widely acknowledged that accurate time estimates for complex projects are somewhere between extremely hard and unfeasible. I don't think a year is a question of accuracy, it usually indicates that the code is becoming lasagna (if no result can be provided), ravioli (if result can be provided but it doesn't work) or spaghetti (when it can be provided and works... sometimes). That sounds exactly like a good use for a maintenance grant, identifying where the existing code base is problematic and trying to tidy it up. That's also not something you can say "will be done by X", it's just something you pour hours and hope end result is easier to work with than the previous state (even if it's still pasta). That's why the Scope of Work (which is the current task) for this is less concerned in end results or deadlines, but in goals which can be attained within a time frame (even if they're "making better" or can only be partly attained, which would cause STF to believe you to be overambitious but is not as problematic as not attaining anything at all). > developers will try to protect themselves by playing it safe and budgeting for the largest amount of time they think they might possibly need. Which means in most cases they will need less time, sometimes significantly less. Would STF be okay with us being so wasteful? No one is going to get paid according to their budget, the payment is over how much time they actually spent. Budget is a limit, so the developer has a good idea since the start of how long they can take. If they notice it'll go over budget, they can stop, reevaluate and propose new budgets or partial deliveries (or whatever the GA/STF decides to be acceptable). More often than not, they'll have run in an unforeseen issue which could warrant a fund/budget on its own. So if you budget 15 hours and work 5, you'll be paid for 5 and the surplus of 10 hours can be given to other projects or assigned somewhere nearing over budgeting so it can be finished (or at least, delivered). > my main point is that the amount of work to be done on any interesting cleanup is unknowable beforehand. That means you have to budget for the worst case, which means in the median case you will be significantly overpaid. I agree it's impossible to know, and I am sure STF is aware of that as well. That's also why particulars usually don't fund these things, but public funds like STF are willing to. But there will be no overpayment, as you're paid for what you do (up to budget). If you finish with less than budgeted, that means the surplus can be used to clean another code. (And if there's a concern of fake hours, there are mechanisms which can be used and can be discussed later, after the budget is made, which is after STF returns their approval and the exact terms). I hope this addresses some of your concerns. Att., Jonatas L. Nogueira (“Jesusalva”) On Wed, Jan 31, 2024, 09:59 Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-01-30 01:15:54) > > > Self-imposed restrictions like these at the very least need a GA vote > > > IMO. > > > > I dont think its a "Self-imposed restriction" > > The right to arbitrarily reject a invoice to a SoW never existed in the > > first place. > > But lets try this hypothetically. > > If the GA decides it has the right to reject an invoice to a SoW > > signed between SPI/STF/1 Developer. > > Where would the GA get that right from ? > > It can only have gained that right from the SoW/ or a contract > > > > This is the same in GSoC > > if the GA
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Michael Niedermayer (2024-01-30 01:15:54) > > Self-imposed restrictions like these at the very least need a GA vote > > IMO. > > I dont think its a "Self-imposed restriction" > The right to arbitrarily reject a invoice to a SoW never existed in the > first place. > But lets try this hypothetically. > If the GA decides it has the right to reject an invoice to a SoW > signed between SPI/STF/1 Developer. > Where would the GA get that right from ? > It can only have gained that right from the SoW/ or a contract > > This is the same in GSoC > if the GA decides a student should not be paid, its not going to > work, its the mentors decission and googles. > The GA never gave that right up, it never had it in the first place My understanding of your > There can be no late objections > [...] > objections after that cannot be considered! was that reviewers of the code produced by an STF-funded project would be restricted from rejecting the patches or demaning large-scale changes. If that is not what you meant then my point does not apply, but then this opens the developer to the risk of their code not being accepted. > > > > > Also once the person doing the work reaches the agreed milestone. > > > She will submit an invoice with stefano and my help to SPI/STF. > > > (in the unlikely case of a dispute on reaching a milestone > > > it would be decided by the technical committee if the milestone > > > has been reached from FFmpegs point of view) > > > > Unlikely? I believe you are overlooking and/or trivializing the most > > serious problems that need to be addressed before we can submit any > > applications and not have it end in disaster. > > yes, iam trivializing, i thought people would value a grant of 200k€ > more than arguing around. IMO hasty actions and avoidable drama may cause damage to the project far in excess of this sum. > And sure some arguments are quite valid i just think we can postpone > what needs to be postponed to get this grant and then for the next > round we can adjust everything as people prefer (in case there then > still is any wish to change something) > > > > > > These are, IMO: > > > > 1) How does the project protect itself from pre-approving some code that > >does not exist yet? This is not just some theoretical danger, it's > >easily possible that some project sounds good in theory, but actually > >implementing it comes with so many gotchas and caveats that it ends > >up being not worth it. Or there are fundamental technical > >disagreements about the specific way it's been implemented. Both > >cases exist in our history. > > Lets see > First STF is not about features but about maintaince. So the risk > of really unexpected and unavoidable sideeffects are not that high. > Also we dont need to do the really tough stuff in STF we can do the > easy but boring stuff. I do not see people queing up for such work. > But whats really the problem here ? > Lets imagine a example we agree to ABC > and it turns out the implemtation of ABC unexpectedly needs 3 letters > and this is unacceptable so we dont merge it. > Personally I would for cases where we arent sure the code is acceptable > for git master. Make this clear to STF before they accepting it and > I would not put "merge into git master" in the SoW. > > Now if we do put something in the SoW that we then do not achieve > thats a failure. IIRC/IIUC this is possible but will not be > tolerated many times. (certainly very dependant also on our > explanation of why that happened) > (thats what i remember, i cannot find the mail ATM where we where told that) The question is, what exactly would be the reprecussion for failing to achieve projects. To us? To SPI? Not to mention the developer not getting paid. > > > >It's also very hard to accurately estimate the amount of work > >required to do something. What do we do when someone spends a month > >working before realizing the project needs 5x more time than it's > >budgeted for? > > use a payment per time SoW. > But honestly as a buisness partner to STF we should aim for delivering > what we promisse at the price we request. > Anything else will not be good for FFmpeg independant of all other things So you're basically saying the developers have to take the risk onto themselves. That's ridiculous and means this cannot be used for almost any interesting projects. As an example, my threading work took over twice the time I initially expected. Are you suggesting I should have worked a year for free? And it's not just my personal failing - it's widely acknowledged that accurate time estimates for complex projects are somewhere between extremely hard and unfeasible. Of course the problem also works in other direction. If we go with your suggestion, developers will try to protect themselves by playing it safe and budgeting for the largest amount of time they think they might possibly need. Which means in most cases they will
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Stefano Sabatini (2024-01-30 00:53:25) > On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-01-28 04:25:49) > > > There can be no late objections here to any project suggestions. > > > Objections must be before a project suggestion is submitted to STF, > > > objections after that cannot be considered! > > > > Self-imposed restrictions like these at the very least need a GA vote > > IMO. > > > > > Also once the person doing the work reaches the agreed milestone. > > > She will submit an invoice with stefano and my help to SPI/STF. > > > (in the unlikely case of a dispute on reaching a milestone > > > it would be decided by the technical committee if the milestone > > > has been reached from FFmpegs point of view) > > > > Unlikely? I believe you are overlooking and/or trivializing the most > > serious problems that need to be addressed before we can submit any > > applications and not have it end in disaster. > > > > These are, IMO: > > The following are good points, I propose some possible solutions. I > think these should be based on the assumptions that failure can > occurr, and the system should be designed to be robust to failures. > > > 1) How does the project protect itself from pre-approving some code that > >does not exist yet? This is not just some theoretical danger, it's > >easily possible that some project sounds good in theory, but actually > >implementing it comes with so many gotchas and caveats that it ends > >up being not worth it. Or there are fundamental technical > >disagreements about the specific way it's been implemented. Both > >cases exist in our history. > > The design and investigative work should be covered as part of the > SOW. In other words, the SOW should also cover the preliminary design > and experimentation. In case it leads to no committable work (which is > unlikely but not impossible), the output should be a document/report > documenting the result of the initial investigation, and the project > might be aborted at that point. > > This should protect both the developer and the project. In each case > it should be assumed that the final result of the investigation would > not lead to committable deliverables, but to design documents which > might lay the foundation of further work (possibly in a different > direction). That might be a viable direction, but it does not really solve the problem. Initial investigation only gets you so far and some issues simply do not become apparent until quite far in the development process. E.g. my recent threading work (that keeps getting mentioned in this thread as an example of what a cleanup project could look like) was largely composed of many "sub-projects", each disentangling a speficic feature or area. And there was no reliable way to predict in advance whether a given sub-project would take two hours or two weeks. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Michael Niedermayer (2024-01-29 22:27:07) > Hi > > On Mon, Jan 29, 2024 at 09:36:27PM +0100, Vittorio Giovara wrote: > > On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote: > > > > > Quoting Vittorio Giovara (2024-01-29 21:09:42) > > > > This is not something that should be discussed on a public ML > > > > > > Where do you think it should be discussed then? > > > > > > > IMO anywhere with a more limited set of constituents, such as the GA or the > > technical committee. > > For the record, the group that was contacted initially by STF was everyone > on the consulting page at the time. > > This probably made sense to STF as they after all wanted to fund people > working. And that page would supposedly list everyone who was available > to do work. > > From there on mainly only one person cared and continued to work on this. > For the record, the list of people on the CC also evolved over time, > one from STF was added, some people seemingly having no interrest disappeared > multiple people related to SPI where added. > > I guess i understand why noone wanted to send this to the ML and i had to ... > > seriously, i dont think anyone had any bad intend here. Yes i wanted it > on the ML long ago and others wanted to first make sure this was real and > actually possible. This ended up being 2 weeks before the next STF meeting > but really everyone just tried to do what they thought best for FFmpeg Who are these 'others' (plural) you speak of? And why did they think they have the right to unilaterally nominate themselves as community representatives? And - since you apparently announced this against their wishes with only a little time to spare - what did they intend to do with the application instead? Submit it without community approval? And why are you defending them instead of them speaking for themselves? It is quite hard not to see this as someone's attempt to strongarm the project into their preferred course of action. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Vittorio On Tue, Jan 30, 2024 at 10:32:42AM +0100, Vittorio Giovara wrote: > On Tue, Jan 30, 2024 at 2:48 AM Michael Niedermayer > wrote: > > > Hi all > > > > after people said they would help and start a wiki page (no not thilo dont > > blame him) > > I again wrote one myself. This is really early WIP > > it contains the application we would send to STF, this is NOT written by me > > and a few random projects > > > > the structure of the application at the end is i think fixed > > so that can be edited but the general structure is specified by STF i think > > > > the stuff above the application is ours and can be changed without > > limitation > > > > I mainly created this page so people can start collaborating on turning > > this into > > what they want it to look like. My version is trash as is, iam aware of > > that > > thats also why i was waiting and hoping someone who is actually good at > > this > > would start it > > > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 > > > Sorry but this feels a lot like "thanks for your feedback, I'm going to do > this anyway". Do you want to take over ? Its not that I want to do this work. Iam just doing it because the majority wants the try to get the grant. But if you think thats not the case and the majority wants to reject it we can do a quick vote of the GA. To formally confirm this. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Rémi On Tue, Jan 30, 2024 at 08:30:56AM +0200, Rémi Denis-Courmont wrote: > > > Le 30 janvier 2024 00:43:39 GMT+02:00, Michael Niedermayer > a écrit : > >Hi > > > >On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote: > >> Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a > >> écrit : [...] > You should step down from the CC IMO because that's very unbecoming of a CC > member (as are your attacks against Kieran) If you believe i have done something wrong towards kieran, you should contact the CC about it. I will certainly not vote on myself. But i will also not back down from my position that 1. STF is a great oppertunity for FFmpeg, and people should be thankfull for the chance to get a ~200k € grant. Not fighting 2. If we dont mess it up now, we will have future opertunities If we act like we do ATM there maybe will not be. > > In these conditions I maintain that this process is inane and discriminatory. Then we should work together to make it better as soon as thats practical > Lastly the FFmpeg community should bot to be taken hostage in one person's > personal feud against FFlabs and/or other companies. (This is purely > hypothetical and not an accusation against anyone in particular. If you feel > targeted, that's on you.) I dont feel targeted. No For the record, i multiple times pushed for compromises between the party hating FFlabs and the party leading it. On one day i chatted for 6 hours with the one not liking FFlabs to try to find a solution. I dont think i succeeded but i tried. So no, i do not hate FFlabs. FFlabs pays me, and iam thankfull for that. That said, I do have disagreements related to FFlabs but that does not belong here. What i can say about FFlabs is that I believe SPI is the better entity to handle FFmpeg Grants, Donations and FFmpeg funds in general. Like anton suggested SPI could pass money on to FFlabs for individuals who want to be working through FFlabs (or another company). I dont see a problem there, From the point of view of STF/SPI the company is the contractor doing the work, how teh company internally handles it is a matter within teh company. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 08:30:56AM +0200, Rémi Denis-Courmont wrote: > > > Le 30 janvier 2024 00:43:39 GMT+02:00, Michael Niedermayer > a écrit : > >Hi > > > >On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote: > >> Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a > >> écrit : > >[...] > >> > Its under the control of the community and its transparent > >> > >> You always have the control of the community at the time of review and > >> merge. > >> > >> You can argue all you want that more open is better. What I see is that > >> this > >> more open is already turning into a train wreck (as predicted last year). > > > >I do have to disagree on this specific point > >The people predicting it to be a train wreck are the people who now make it > >a train wreck. > > That's clearly false and defamatory against me. No, not at all because this statement is not about you at all. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Nicolas George (2024-01-30 11:12:13) > Kieran Kunhya (12024-01-29): > > A commercial SOW with a private company that took the commercial risk on > > that contract taking longer or being more difficult than anticipated or > > someone else doing the work without telling them. > > > > The terms of that contract were discussed in private and don't affect the > > project itself. > > It does not affect the project itself except in resulting in a patch > series that was developer all alone, wasting the benefit of having > several competent people contributing ideas for the core design, and an > attitude of urgency and closed-mindedness for anything that would delay > applying the series once it was posted, even if it was severe breakage > of features. All of these are objectively false. Preliminary cleanup patches first appeared on the ML in December 2021. The project was then publicly announced in April 2022. The work was upstreamed continually, in a total of ~50 small-to-medium patchsets over the course of ~2 years. The final threading conversion patches were submitted to the ML 3 months before being merged upstream. There was ample opportunity for anyone to comment all along the way, I actually wish more people had used it. You're just salty you got overruled. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 11:15 AM Nicolas George wrote: > Vittorio Giovara (12024-01-30): > > Sorry, but this feels a lot like “I have nothing to add to the > > conversation, but I feel like I need to speak up anyway”. > > Well... > > > It's not a veto when multiple eminent contributors outlined the problems > > with the current proposals, and I don't think ignoring them is beneficial > > to the community. I'm surprised I have to explain this *once again*. > > When several people say no and several people say yes, at the end, > whatever the chosen answer, some will feel they have been ignored. But > it is just a feeling. > > I am surprised to have to explain this at all. > Thanks for derailing the conversation and proving my point while at it. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, 30 Jan 2024 at 10:46, Nicolas George wrote: > Kieran Kunhya (12024-01-30): > > So you agree the proposed Statement of Work idea in this thread isn't > going > > to fly as it won't cover actual code review? > > If that is what you read in what I wrote, I suggest you take reading > lessons intended for an early age. > Thank you for proving my point that you will be the first to block a Statement of Work. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Kieran Kunhya (12024-01-30): > So you agree the proposed Statement of Work idea in this thread isn't going > to fly as it won't cover actual code review? If that is what you read in what I wrote, I suggest you take reading lessons intended for an early age. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, 30 Jan 2024 at 10:31, Nicolas George wrote: > Kieran Kunhya (12024-01-30): > > The patches were on the mailing list for months, there was a presentation > > at VDD (livestreamed too). > > “But Mr. Dent, the plans have been available in the local planning > office for the last nine month.” — Douglas Adams > So you agree the proposed Statement of Work idea in this thread isn't going to fly as it won't cover actual code review? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Kieran Kunhya (12024-01-30): > The patches were on the mailing list for months, there was a presentation > at VDD (livestreamed too). “But Mr. Dent, the plans have been available in the local planning office for the last nine month.” — Douglas Adams -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, 30 Jan 2024 at 10:12, Nicolas George wrote: > Kieran Kunhya (12024-01-29): > > A commercial SOW with a private company that took the commercial risk on > > that contract taking longer or being more difficult than anticipated or > > someone else doing the work without telling them. > > > > The terms of that contract were discussed in private and don't affect the > > project itself. > > It does not affect the project itself except in resulting in a patch > series that was developer all alone, wasting the benefit of having > several competent people contributing ideas for the core design, and an > attitude of urgency and closed-mindedness for anything that would delay > applying the series once it was posted, even if it was severe breakage > of features. > The patches were on the mailing list for months, there was a presentation at VDD (livestreamed too). Though you are proving my objections to this statement of work fallacy which is great. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Vittorio Giovara (12024-01-30): > Sorry, but this feels a lot like “I have nothing to add to the > conversation, but I feel like I need to speak up anyway”. Well... > It's not a veto when multiple eminent contributors outlined the problems > with the current proposals, and I don't think ignoring them is beneficial > to the community. I'm surprised I have to explain this *once again*. When several people say no and several people say yes, at the end, whatever the chosen answer, some will feel they have been ignored. But it is just a feeling. I am surprised to have to explain this at all. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 11:07 AM Nicolas George wrote: > Vittorio Giovara (12024-01-30): > > Sorry but this feels a lot like "thanks for your feedback, I'm going to > do > > this anyway". > > Sorry, but this feels a lot like “I gave an objection, you have to treat > it like a veto”. > Sorry, but this feels a lot like “I have nothing to add to the conversation, but I feel like I need to speak up anyway”. It's not a veto when multiple eminent contributors outlined the problems with the current proposals, and I don't think ignoring them is beneficial to the community. I'm surprised I have to explain this *once again*. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Kieran Kunhya (12024-01-29): > A commercial SOW with a private company that took the commercial risk on > that contract taking longer or being more difficult than anticipated or > someone else doing the work without telling them. > > The terms of that contract were discussed in private and don't affect the > project itself. It does not affect the project itself except in resulting in a patch series that was developer all alone, wasting the benefit of having several competent people contributing ideas for the core design, and an attitude of urgency and closed-mindedness for anything that would delay applying the series once it was posted, even if it was severe breakage of features. But sure, let us pretend that corporate meddling with FFmpeg is not harmful to the project. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Vittorio Giovara (12024-01-30): > Sorry but this feels a lot like "thanks for your feedback, I'm going to do > this anyway". Sorry, but this feels a lot like “I gave an objection, you have to treat it like a veto”. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 2:48 AM Michael Niedermayer wrote: > Hi all > > after people said they would help and start a wiki page (no not thilo dont > blame him) > I again wrote one myself. This is really early WIP > it contains the application we would send to STF, this is NOT written by me > and a few random projects > > the structure of the application at the end is i think fixed > so that can be edited but the general structure is specified by STF i think > > the stuff above the application is ours and can be changed without > limitation > > I mainly created this page so people can start collaborating on turning > this into > what they want it to look like. My version is trash as is, iam aware of > that > thats also why i was waiting and hoping someone who is actually good at > this > would start it > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 Sorry but this feels a lot like "thanks for your feedback, I'm going to do this anyway". -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
mån 2024-01-29 klockan 21:04 +0100 skrev Michael Niedermayer: > On Mon, Jan 29, 2024 at 07:02:57PM +, Kieran Kunhya wrote: > > On Mon, 29 Jan 2024, 18:54 Michael Niedermayer, > > > > wrote: > > > > > > > > > You weren't willing to compromise last time > > > > for your hobby, what makes you willing to compromise in that > > > > situation? > > > > > > This insult is unacceptable. > > > I just a few days ago stated that i intend to implement SDR > > > within what the > > > community prefers or as a seperate fork. > > > So thats completely the opposit of what i stated > > > > > > > I obviously just dreamt up the most serious schism in the project > > since the > > fork. > > In that case, please wake up > > > > > > I mean there's SDR related code in git right now, you're literally > > gaslighting at this point. > > You are talking about > "avcodec: Rename ff_kbd_window_init() as it will be needed from > outside libavcodec" > https://github.com/FFmpeg/FFmpeg/commit/fd5aa93a37b3fa21195c6d7b22ef655124020e09 > > and > > "avcodec/kbdwin: Support arbitrary sized windows" > https://github.com/FFmpeg/FFmpeg/commit/cf00f60bab1f79213c274a6cd4357b32bd5c0101 There is also making PCM formats suddenly able to change codecpars (94d44db) which I'm sure will have some effects for downstream projects that expect PCM to be a "dumb" format. /Tomas ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Le 29 janvier 2024 22:15:39 GMT+02:00, Derek Buitenhuis a écrit : >Between this, the unaswered NAB questions, the second vote ridiculousness, the >accidental email to the ML from Thilo where he admits he has purposely not >replied, >etc., Also - Reject FFmpeg project's free invitation to SCaLE because he wouldn't participate, rather than pass it on. ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Le 30 janvier 2024 00:43:39 GMT+02:00, Michael Niedermayer a écrit : >Hi > >On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote: >> Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit >> : >[...] >> > Its under the control of the community and its transparent >> >> You always have the control of the community at the time of review and merge. >> >> You can argue all you want that more open is better. What I see is that this >> more open is already turning into a train wreck (as predicted last year). > >I do have to disagree on this specific point >The people predicting it to be a train wreck are the people who now make it >a train wreck. That's clearly false and defamatory against me. And given that you were the one to ask for feedback and project ideas that also constitutes entrapment. You should step down from the CC IMO because that's very unbecoming of a CC member (as are your attacks against Kieran) In these conditions I maintain that this process is inane and discriminatory. Lastly the FFmpeg community should bot to be taken hostage in one person's personal feud against FFlabs and/or other companies. (This is purely hypothetical and not an accusation against anyone in particular. If you feel targeted, that's on you.) ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi all after people said they would help and start a wiki page (no not thilo dont blame him) I again wrote one myself. This is really early WIP it contains the application we would send to STF, this is NOT written by me and a few random projects the structure of the application at the end is i think fixed so that can be edited but the general structure is specified by STF i think the stuff above the application is ours and can be changed without limitation I mainly created this page so people can start collaborating on turning this into what they want it to look like. My version is trash as is, iam aware of that thats also why i was waiting and hoping someone who is actually good at this would start it https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi all I just now realize you already CC-ed jonatan and he already awnsered sorry for the noise On Tue, Jan 30, 2024 at 01:15:54AM +0100, Michael Niedermayer wrote: > Hi Anton, > > CCing Jonatas as there are questions beyond my knowledge in here > and also iam not sure if my awnsers are all correct [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Anton, CCing Jonatas as there are questions beyond my knowledge in here and also iam not sure if my awnsers are all correct On Mon, Jan 29, 2024 at 10:11:49PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-01-28 04:25:49) > > There can be no late objections here to any project suggestions. > > Objections must be before a project suggestion is submitted to STF, > > objections after that cannot be considered! > > Self-imposed restrictions like these at the very least need a GA vote > IMO. I dont think its a "Self-imposed restriction" The right to arbitrarily reject a invoice to a SoW never existed in the first place. But lets try this hypothetically. If the GA decides it has the right to reject an invoice to a SoW signed between SPI/STF/1 Developer. Where would the GA get that right from ? It can only have gained that right from the SoW/ or a contract This is the same in GSoC if the GA decides a student should not be paid, its not going to work, its the mentors decission and googles. The GA never gave that right up, it never had it in the first place > > > Also once the person doing the work reaches the agreed milestone. > > She will submit an invoice with stefano and my help to SPI/STF. > > (in the unlikely case of a dispute on reaching a milestone > > it would be decided by the technical committee if the milestone > > has been reached from FFmpegs point of view) > > Unlikely? I believe you are overlooking and/or trivializing the most > serious problems that need to be addressed before we can submit any > applications and not have it end in disaster. yes, iam trivializing, i thought people would value a grant of 200k€ more than arguing around. And sure some arguments are quite valid i just think we can postpone what needs to be postponed to get this grant and then for the next round we can adjust everything as people prefer (in case there then still is any wish to change something) > > These are, IMO: > > 1) How does the project protect itself from pre-approving some code that >does not exist yet? This is not just some theoretical danger, it's >easily possible that some project sounds good in theory, but actually >implementing it comes with so many gotchas and caveats that it ends >up being not worth it. Or there are fundamental technical >disagreements about the specific way it's been implemented. Both >cases exist in our history. Lets see First STF is not about features but about maintaince. So the risk of really unexpected and unavoidable sideeffects are not that high. Also we dont need to do the really tough stuff in STF we can do the easy but boring stuff. But whats really the problem here ? Lets imagine a example we agree to ABC and it turns out the implemtation of ABC unexpectedly needs 3 letters and this is unacceptable so we dont merge it. Personally I would for cases where we arent sure the code is acceptable for git master. Make this clear to STF before they accepting it and I would not put "merge into git master" in the SoW. Now if we do put something in the SoW that we then do not achieve thats a failure. IIRC/IIUC this is possible but will not be tolerated many times. (certainly very dependant also on our explanation of why that happened) (thats what i remember, i cannot find the mail ATM where we where told that) Again i would suggest to word the SoW in a clear and honest way maybe "work 1 year full time on ffmpeg-CLI multithreading" NOT "produce a finished implemtation of ffmpeg-CLI multithreading in a year" than again iam not sure this above wouldnt be a "feature" If this would be accepted i dont know. But its what i would do It simply puts in words the truth what we can promise (that we will work on this for that time and we also in such a case should explain why we cannot state clearly why we cant promise a specific result at a specific time) > > 2) How do developers protect themselves from spending vast amounts of >time on work they may not get paid for? As per 1), we may easily run >into fundamental technical disagreements which result in the work >having to be scrapped or redone entirely. IIUC payment can be per milestone or per time. in both cases the developer will send an invoice when reaching the agreed points. I think its expected that the code would not be finished and in git master at that point. > >It's also very hard to accurately estimate the amount of work >required to do something. What do we do when someone spends a month >working before realizing the project needs 5x more time than it's >budgeted for? use a payment per time SoW. But honestly as a buisness partner to STF we should aim for delivering what we promisse at the price we request. Anything else will not be good for FFmpeg independant of all other things > > 3) Who exactly will be judging what amount of money is appropriate for >what amount of work performed? How will we avoid conflicts of >
Re: [FFmpeg-devel] Sovereign Tech Fund
On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-01-28 04:25:49) > > There can be no late objections here to any project suggestions. > > Objections must be before a project suggestion is submitted to STF, > > objections after that cannot be considered! > > Self-imposed restrictions like these at the very least need a GA vote > IMO. > > > Also once the person doing the work reaches the agreed milestone. > > She will submit an invoice with stefano and my help to SPI/STF. > > (in the unlikely case of a dispute on reaching a milestone > > it would be decided by the technical committee if the milestone > > has been reached from FFmpegs point of view) > > Unlikely? I believe you are overlooking and/or trivializing the most > serious problems that need to be addressed before we can submit any > applications and not have it end in disaster. > > These are, IMO: The following are good points, I propose some possible solutions. I think these should be based on the assumptions that failure can occurr, and the system should be designed to be robust to failures. > 1) How does the project protect itself from pre-approving some code that >does not exist yet? This is not just some theoretical danger, it's >easily possible that some project sounds good in theory, but actually >implementing it comes with so many gotchas and caveats that it ends >up being not worth it. Or there are fundamental technical >disagreements about the specific way it's been implemented. Both >cases exist in our history. The design and investigative work should be covered as part of the SOW. In other words, the SOW should also cover the preliminary design and experimentation. In case it leads to no committable work (which is unlikely but not impossible), the output should be a document/report documenting the result of the initial investigation, and the project might be aborted at that point. This should protect both the developer and the project. In each case it should be assumed that the final result of the investigation would not lead to committable deliverables, but to design documents which might lay the foundation of further work (possibly in a different direction). > 2) How do developers protect themselves from spending vast amounts of >time on work they may not get paid for? As per 1), we may easily run >into fundamental technical disagreements which result in the work >having to be scrapped or redone entirely. > >It's also very hard to accurately estimate the amount of work >required to do something. What do we do when someone spends a month >working before realizing the project needs 5x more time than it's >budgeted for? Assuming a SOW can be split in several parts, the first one being the initial investigation, and assuming that the developer can split her work in parts, and that only the first one (the one about the initial investigation) can be invoiced in case there is no consensus about the actual implementation. Again, I don't think this is very likely to happen, but we should have a mechanism to handle this (and protect both the project and the developer committing the work), in order to minimize the risk. > 3) Who exactly will be judging what amount of money is appropriate for >what amount of work performed? How will we avoid conflicts of >interest, or endless bikesheds over who is getting too much money for >too little work? We just bikeshud a thread to death over rather >little money, now imagine what would happen with ten times the >amount. The amount of money might be defined based on economic parameters related to the living country of the developer and according an estimated amount of time. This is not perfect but it's probably the best we can come around. As per the final decision (e.g. in case there is no community consensus after the investigatory stage) probably the Technical Committee should be involved. This assumes that once the TC committee reaches a decision, this cannot be reverted. At the end this is one of the reasons why the TC exists in the first place, use delegation to reach consensus in case the overall community cannot find it. > Contrary to the overall mood of this thread so far, I hope these issues > can be overcome and some useful work sponsored successfully. But they > need to be taken seriously first. > > I'd also like to ask Jonatas whether anything requires the projects to > be owned by individuals. Were I to propose a project, I'd much rather it > went through FFlabs than myself individually. Also it would probably help to define the areas for the candidate projects, I can think several things related to documentation for example like completing/reviewing the documentation for the missing parts which belong to low-risk area (note: I would not be able to apply for any SOW given my employment status). Probably it would help, if rather than discussing these
Re: [FFmpeg-devel] Sovereign Tech Fund
Anton: "whether anything requires the projects to be owned by individuals"... I don't think so. At least, not from the SPI side, STF might have objections which I cannot anticipate. But from the SPI side, we probably could do a MSA/SOW with a company rather than individuals just fine, although I would still have to check with the attorney though as our MSA and SOW are optimized for individuals. As long as the final price is something that SPI, STF, IRS, and Bundestag can agree with and the job is within the scope of work, that is. In such case, STF would transfer money to SPI, SPI would sign a SOW with FFlabs, FFlabs would hire you (this has some implications, like FFlabs owning the code), then FFlabs would report completion to SPI, SPI would check if the complete work is according the SOW (peer-review + liaison approval/veto), and if everything is good, SPI would pay FFlabs. With individuals: STF would transfer money to SPI, SPI would sign a SOW with every developer, then the developer would report completion to SPI, SPI would check if the complete work is according the SOW (peer-review + liaison approval/veto), and if everything is good, SPI would pay the developer directly. Note 1: Please don't forget that the idea of the currently discussed grant, as I understand it, is maintenance and security work, not projects, so while one would need the finished Scope of Work to be sure, I don't expect #1 (pre-approval) to be an actual issue. Note 2: Doing this with a company is usually more expensive than contracting with the devs directly, so as I said, you would need to check with STF, and just like SPI won't pay for developers without the deliverables, same apply to a company (where the company could still need to pay the developers anyway). Note 3: What you need more urgently is the Scope of Work. From what you said, you might even want the GA to vote on it, and if you take a whole week for it as advised in your FAQ, then you need it done even earlier, by February 5th, giving you exactly a week to finish this. There are several potential solutions for the other issues, including practical ones like e.g. a document from the General Assembly making an incomplete MR/PR equivalent to a commit, or impractical ones like e.g. requiring all contractors to record their screens while doing the tasks and sending the low-res video to confirm they work, but none of them matter if the Scope of Work cannot be finished in time. Note 4: I am an outsider, external to FFmpeg ─ my goal here is to answer questions and support you in securing the funding. I'm not paid by SPI to do this, my time is not infinite and the time I can spare is not exclusive for FFmpeg but has to be shared among all the 42 SPI associated projects, so I would highly appreciate if you could be topical, that is, leave "dirty laundry", votes of no-confidence and such to the Community Committee and keep here only the immediately relevant part for getting the sponsorship unblocked (e.g. "The Technical Committee should send a list of contested commits and SPI should delay payment over those until the TC issues a decision"). Offtopic not only derails but wastes everyone's time. Would it help if I set up a shared Google Docs? I'm here to answer questions, but if you're in need of support of any kind just ask. I'm honestly rooting for FFmpeg to succeed, after all, even if it doesn't matter much for SPI if you decide you are better off without funding, maintaining your code or hiring help for security tasks. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Mon, Jan 29, 2024 at 6:11 PM Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-01-28 04:25:49) > > There can be no late objections here to any project suggestions. > > Objections must be before a project suggestion is submitted to STF, > > objections after that cannot be considered! > > Self-imposed restrictions like these at the very least need a GA vote > IMO. > > > Also once the person doing the work reaches the agreed milestone. > > She will submit an invoice with stefano and my help to SPI/STF. > > (in the unlikely case of a dispute on reaching a milestone > > it would be decided by the technical committee if the milestone > > has been reached from FFmpegs point of view) > > Unlikely? I believe you are overlooking and/or trivializing the most > serious problems that need to be addressed before we can submit any > applications and not have it end in disaster. > > These are, IMO: > > 1) How does the project protect itself from pre-approving some code that >does not exist yet? This is not just some theoretical danger, it's >easily possible that some project sounds good in theory, but actually >implementing it comes with so many gotchas and caveats that it ends >up being not worth it. Or there are fundamental technical >disagreements about the specific way it's been implemented. Both >cases exist in our
Re: [FFmpeg-devel] Sovereign Tech Fund
> > I guess that conculdes the "most serious schism in the project since the > fork" > until the next most serious ? > If you think that was the sole consequence of your attempt to ram SDR into ffmpeg then I have no words. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote: > Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit : [...] > > Its under the control of the community and its transparent > > You always have the control of the community at the time of review and merge. > > You can argue all you want that more open is better. What I see is that this > more open is already turning into a train wreck (as predicted last year). I do have to disagree on this specific point The people predicting it to be a train wreck are the people who now make it a train wreck. > > > And very important what do you propose ? > > We already went through this in the previous thread last year. This is not > going to work in the light of what Jonatas politely calls FFmpeg "governance" > challenges. It was already clear that finding agreement within the GA would > be > at best very difficult and untimely. > > People (including myself) already suggested to arrange that sort of things > via > an IT service company (*not* necessarily FFlabs). Or you could even go > through > a "porting" company in your country if you can't find an existing agreeable > company and don't want to register your own. Of course those are not perfect > solutions but they seem far less fraught with problems than going through a > foundation, especially a US-based foundation. You can review the archives for > details. Of course we can discuss this and vote on it. Personally i believe SPI is a good choice. And especially a safe choice. And it will be difficult to find a choice that doesnt have some agenda and does this for free. SPI has served many open source projects over a long time. Adding an entity that handles FFmpegs finanaces needs to be done carefully It should not be a newly formed entity and it should not be an entity related to multimedia. So for example a >10 year old entity that is truted by many diverse open source projects. (like SPI) But either way that would not be a quick process finding an entity that everyone trusts wouĺd not be easy. So i still suggest we go with SPI even for future STF rounds [...] > > > That drama > > > couldn't be had for GSoC because how was however Google decides, and there > > > was no intermediary to go through (money went straight from Google to the > > > students). > > > > SPI handles all the GSoC mentor money. > > And lets just assume it would handle the students money too, what difference > > would that really make ? > > It would cause similar arguments to this one. And that's if Google would even > agree to such a setup (which I guess they wouldn't). > > What is the point of going through SPI for *this* (as opposed to regular > donations)? iam not 100% sure i understand your question. Our donations are handled by SPI and STF will not pay developers directly, this is not an option. This was asked early 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" signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, 29 Jan 2024, 22:23 Cosmin Stejerean via ffmpeg-devel, < ffmpeg-devel@ffmpeg.org> wrote: > > > > On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote: > > > > So work like Anton's threading, YUVJ removal etc, that couldn't be funded > > via bounties as they have no direct commercial value but require > expertise > > in the codebase. > > Statements of Work and milestones (by definition) are for features. > > I'm not sure those are the best examples to make that point given that > both multi-threading and YUVJ removal were funded by commercial SOWs. > > - Cosmin > A commercial SOW with a private company that took the commercial risk on that contract taking longer or being more difficult than anticipated or someone else doing the work without telling them. The terms of that contract were discussed in private and don't affect the project itself. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
> On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote: > > So work like Anton's threading, YUVJ removal etc, that couldn't be funded > via bounties as they have no direct commercial value but require expertise > in the codebase. > Statements of Work and milestones (by definition) are for features. I'm not sure those are the best examples to make that point given that both multi-threading and YUVJ removal were funded by commercial SOWs. - 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Kieran Kunhya (2024-01-28 20:34:46) > The threading changes took the best part of a year and are still ongoing. Over two years actually. I started working on it in November 2021. And I agree that estimating the amount of work needed is a HUGE problem, in both directions. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi On Mon, Jan 29, 2024 at 09:36:27PM +0100, Vittorio Giovara wrote: > On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote: > > > Quoting Vittorio Giovara (2024-01-29 21:09:42) > > > This is not something that should be discussed on a public ML > > > > Where do you think it should be discussed then? > > > > IMO anywhere with a more limited set of constituents, such as the GA or the > technical committee. For the record, the group that was contacted initially by STF was everyone on the consulting page at the time. This probably made sense to STF as they after all wanted to fund people working. And that page would supposedly list everyone who was available to do work. From there on mainly only one person cared and continued to work on this. For the record, the list of people on the CC also evolved over time, one from STF was added, some people seemingly having no interrest disappeared multiple people related to SPI where added. I guess i understand why noone wanted to send this to the ML and i had to ... seriously, i dont think anyone had any bad intend here. Yes i wanted it on the ML long ago and others wanted to first make sure this was real and actually possible. This ended up being 2 weeks before the next STF meeting but really everyone just tried to do what they thought best for FFmpeg thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Diederick C. Niehorster (2024-01-29 21:41:29) > On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara > wrote: > > > > On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer > > wrote: > > > > > > I have yet to see an actual project of "this magnitude" materialize as a > > > proposal. > > > > > > you can suggest one ? > > > > > > > libavscale! > > Not being a regular, this may not count for much. But this sounds like > a great opportunity, lets not pass it up. Projects i have seen on the > mailing list over the last two years or so that i remember and should > be of interest: > - swscale rewrite/update/extension > - deal with the libavdevice situation > - remove postproc > - Nicolas various utility proposals for strings, options, etc > - hell, even a better infrastructure for dealing with incoming patches > and tests surrounding them, using pull requests, automatic CI fate > runs upon incoming pull requests, etc. The main problem with most of these is not funding, it's lack of agreement on what should be done. In some cases even on basic direction things should move in. The potential issues mentioned in this thread would be extra likely to materialize then. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Michael Niedermayer (2024-01-28 04:25:49) > There can be no late objections here to any project suggestions. > Objections must be before a project suggestion is submitted to STF, > objections after that cannot be considered! Self-imposed restrictions like these at the very least need a GA vote IMO. > Also once the person doing the work reaches the agreed milestone. > She will submit an invoice with stefano and my help to SPI/STF. > (in the unlikely case of a dispute on reaching a milestone > it would be decided by the technical committee if the milestone > has been reached from FFmpegs point of view) Unlikely? I believe you are overlooking and/or trivializing the most serious problems that need to be addressed before we can submit any applications and not have it end in disaster. These are, IMO: 1) How does the project protect itself from pre-approving some code that does not exist yet? This is not just some theoretical danger, it's easily possible that some project sounds good in theory, but actually implementing it comes with so many gotchas and caveats that it ends up being not worth it. Or there are fundamental technical disagreements about the specific way it's been implemented. Both cases exist in our history. 2) How do developers protect themselves from spending vast amounts of time on work they may not get paid for? As per 1), we may easily run into fundamental technical disagreements which result in the work having to be scrapped or redone entirely. It's also very hard to accurately estimate the amount of work required to do something. What do we do when someone spends a month working before realizing the project needs 5x more time than it's budgeted for? 3) Who exactly will be judging what amount of money is appropriate for what amount of work performed? How will we avoid conflicts of interest, or endless bikesheds over who is getting too much money for too little work? We just bikeshud a thread to death over rather little money, now imagine what would happen with ten times the amount. Contrary to the overall mood of this thread so far, I hope these issues can be overcome and some useful work sponsored successfully. But they need to be taken seriously first. I'd also like to ask Jonatas whether anything requires the projects to be owned by individuals. Were I to propose a project, I'd much rather it went through FFlabs than myself individually. Cheers, -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit : > > The "drama" is about how and through whom the funding goes. > > ok, elaborate please > > All FFmpeg money has always been handled through SPI or associated entities It was already a bit of a stretch to compare GSoC students with (hypothetical) STF subcontractors. So sorry but I simply don't think that the funding for mentors is comparable at all. In fact, it seems completely normal for the GSoC mentor funding to go via open-source foundations, and other GSoC projects presumably operate the same way. > Its under the control of the community and its transparent You always have the control of the community at the time of review and merge. You can argue all you want that more open is better. What I see is that this more open is already turning into a train wreck (as predicted last year). > And very important what do you propose ? We already went through this in the previous thread last year. This is not going to work in the light of what Jonatas politely calls FFmpeg "governance" challenges. It was already clear that finding agreement within the GA would be at best very difficult and untimely. People (including myself) already suggested to arrange that sort of things via an IT service company (*not* necessarily FFlabs). Or you could even go through a "porting" company in your country if you can't find an existing agreeable company and don't want to register your own. Of course those are not perfect solutions but they seem far less fraught with problems than going through a foundation, especially a US-based foundation. You can review the archives for details. And it certainly does not help that this only became public so late in the process, which is intrinsically suspicious. > Should we reject the maybe 200k € grant we could get from STF now ? Again, nobody objected to getting funding from STF as such. > > That drama > > couldn't be had for GSoC because how was however Google decides, and there > > was no intermediary to go through (money went straight from Google to the > > students). > > SPI handles all the GSoC mentor money. > And lets just assume it would handle the students money too, what difference > would that really make ? It would cause similar arguments to this one. And that's if Google would even agree to such a setup (which I guess they wouldn't). What is the point of going through SPI for *this* (as opposed to regular donations)? -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara wrote: > > On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer > wrote: > > > > I have yet to see an actual project of "this magnitude" materialize as a > > proposal. > > > > you can suggest one ? > > > > libavscale! Not being a regular, this may not count for much. But this sounds like a great opportunity, lets not pass it up. Projects i have seen on the mailing list over the last two years or so that i remember and should be of interest: - swscale rewrite/update/extension - deal with the libavdevice situation - remove postproc - Nicolas various utility proposals for strings, options, etc - hell, even a better infrastructure for dealing with incoming patches and tests surrounding them, using pull requests, automatic CI fate runs upon incoming pull requests, etc. These are issues that are either maintenance or infrastructure work, unlikely to be funded by companies, but can help the whole project forward. I know a bunch of these are contentious, but they are worth exploring. You all probably have ten more better ideas since you know the project better. Please focus on getting something together. I fail to see serious issues. This is not a vehicle for some company interest or closed source interest to influence the project. This is not a vehicle for some unpopular minority opinion on a direction the project should take to get pushed through. This is not unfair in its distribution by nature--suggest something you'd like to work on, this is a good chance to get it funded. I understand there are potentially legitimate issues around project management that come up here again. Of course these should be discussed. But do so in parallel to moving forward and putting an application together. All the best, Dee ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote: > Quoting Vittorio Giovara (2024-01-29 21:09:42) > > This is not something that should be discussed on a public ML > > Where do you think it should be discussed then? > IMO anywhere with a more limited set of constituents, such as the GA or the technical committee. I, for one, see a much bigger problem in the fact that it only starts > being discussed on the ML this late, after so much underground dealings > that bypassed the community entirely. > Of course, I cannot disagree there. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On 1/29/2024 8:19 PM, Anton Khirnov wrote: > I, for one, see a much bigger problem in the fact that it only starts > being discussed on the ML this late, after so much underground dealings > that bypassed the community entirely. +1 - Derek ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Vittorio Giovara (2024-01-29 21:09:42) > This is not something that should be discussed on a public ML Where do you think it should be discussed then? I, for one, see a much bigger problem in the fact that it only starts being discussed on the ML this late, after so much underground dealings that bypassed the community entirely. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On 1/29/2024 8:09 PM, Vittorio Giovara wrote: > This is not something that should be discussed on a public ML and the lack > of visibility and clarity on how SPI/STM got involved this time around is > at least disingenuous IMO. I am more curious how Thilo managed to insert himself as the sole representative of the community without anyone else knowing this stuff existed at all. Between this, the unaswered NAB questions, the second vote ridiculousness, the accidental email to the ML from Thilo where he admits he has purposely not replied, etc., I intend to raise this for discussion at the FOSDEM meeting. It is so sketchy. - Derek ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer wrote: > > I have yet to see an actual project of "this magnitude" materialize as a > proposal. > > you can suggest one ? > libavscale! or there is nothing you want improved in FFmpeg ? > Or only if SPI isnt involved or iam not sure what exactly you want > different ? > I, for one, would love to stop seeing flame threads about funding FFmpeg that lead to nowhere. This is not something that should be discussed on a public ML and the lack of visibility and clarity on how SPI/STM got involved this time around is at least disingenuous IMO. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 07:02:57PM +, Kieran Kunhya wrote: > On Mon, 29 Jan 2024, 18:54 Michael Niedermayer, > wrote: > > > > > > You weren't willing to compromise last time > > > for your hobby, what makes you willing to compromise in that situation? > > > > This insult is unacceptable. > > I just a few days ago stated that i intend to implement SDR within what the > > community prefers or as a seperate fork. > > So thats completely the opposit of what i stated > > > > I obviously just dreamt up the most serious schism in the project since the > fork. In that case, please wake up > > I mean there's SDR related code in git right now, you're literally > gaslighting at this point. You are talking about "avcodec: Rename ff_kbd_window_init() as it will be needed from outside libavcodec" https://github.com/FFmpeg/FFmpeg/commit/fd5aa93a37b3fa21195c6d7b22ef655124020e09 and "avcodec/kbdwin: Support arbitrary sized windows" https://github.com/FFmpeg/FFmpeg/commit/cf00f60bab1f79213c274a6cd4357b32bd5c0101 The first makes the function available outside libavcodec the 2nd makes it work with bigger sizes. If that was the "most serious schism in the project since the fork" Iam sure you are ecstatic to hear i just approved these 2 being reverted ill just copy the 1 page of code where its needed instead. I guess that conculdes the "most serious schism in the project since the fork" until the next most serious ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Derek On Mon, Jan 29, 2024 at 06:37:44PM +, Derek Buitenhuis wrote: > >> On 1/28/2024 3:25 AM, Michael Niedermayer wrote: > >> As others have said, the whole model of using discrete projects here seems > >> opposed to > >> the actual intent of the STF - maintained and stable OSS long term. > > > > The whole suggestion here is based on what STF and SPI said. There was a > > conference > > between SPI and STF where they worked the details out. > > Also all the things SPI told us had STF in CC. > > What SPI convinced STF is best is not necessarily the same. Thats true, you are absolutely correct. But it also might be the best Thats why one iterates. One starts somewhere, looks at what works, what doesnt and adjusts. > > Also notably missing here is the community (as in, more than just Thilo) > having > any access to review, comment, or help direct this. You know i wanted this on the ML months ago. Other people believed we need to wait until everything is known to be possible ... But now the community is here (most are being silent) but thouse not silent are heared. And we can and will adapt to it. If we get another chance at STF next year or even before that. We can collect all ideas and questions on a wiki page and pass them to STF and SPI. ATM the question is about this feb this year, we have 2 weeks for this application, thats not much time but it is time, we can certainly adjust things even now if there are specific suggestions. [...] > >> Furthermore, we *already* have a bunch of money sitting in SPI funds that > >> *is* suitable > >> for use on discete projects, but it never gets used. It is a poor way to > >> encourage useful > >> work, IMO. > > > > Theres a very big difference. we have around 100k USD in SPI > > > > STF has a lower limit of 150.000 € so we actually need to ask them for > > at least 150k to be qualified IIUC > > And honestly if you reject that, i just dont understand you. > > "Estimated costs: The cost of the work described in the application must > > exceed €150,000 (current minimum)." > > > > AT no point could we have done anything with SPI money in a similar > > magnitude. In fact trying to use SPI money for any work failed because of it > > not being enough. > > I have yet to see an actual project of "this magnitude" materialize as a > proposal. you can suggest one ? or there is nothing you want improved in FFmpeg ? Or only if SPI isnt involved or iam not sure what exactly you want different ? 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 signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, 29 Jan 2024, 18:54 Michael Niedermayer, wrote: > > > You weren't willing to compromise last time > > for your hobby, what makes you willing to compromise in that situation? > > This insult is unacceptable. > I just a few days ago stated that i intend to implement SDR within what the > community prefers or as a seperate fork. > So thats completely the opposit of what i stated > I obviously just dreamt up the most serious schism in the project since the fork. I mean there's SDR related code in git right now, you're literally gaslighting at this point. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Kieran On Mon, Jan 29, 2024 at 06:31:30PM +, Kieran Kunhya wrote: > On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer > wrote: > > > Hi Kieran > > > > On Sun, Jan 28, 2024 at 08:42:00PM +, Kieran Kunhya wrote: > > > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote: > > > > > > > Both work fine really. For example iam not employed by FFlabs and the > > work > > > >> i did for them is just by sending invoices, while what i do qualifies > > > >> maintenance probably close to 100%. > > > >> > > > > > > > > Fflabs is a private company that can choose however it likes how to > > > > distribute its funds. STF/SPI/FFmpeg are not the same. > > > > > > > > Would you like every invoice you make to be on this mailing list and > > > > discussed in depth in public? And if that invoice was voted against by > > the > > > > GA what would you do? > > > > > > > > Kieran > > > > > > > > > > Remember the outcry about SDR that literally drove people away from the > > > project? Well imagine that for one of your invoices. > > > > Do you mean it would drive them away because of how much or how little i > > work for ? > > Or becuase of what i work for ? > > > > You refused to acknowledge the public outcry over SDR for months and pushed > patches the community clearly objected to (see andreas thread). 1. thats not true, SDR was not pushed to git master 2. there is a technical committee for disagreements, if there was a dissagreemnet but the technical committee was not contacted 3. I see how you try to move the argument from a ~ 200k € grant that noone in their right mind would reject to arguing over some unpopular code. SDR does not fit within the STF framework so this doesnt even work even if we all tried together to make it work. Also everything needs to be approved by the community before STF can fund it so there are so many indepedant reasons why this i impossible [...] > You weren't willing to compromise last time > for your hobby, what makes you willing to compromise in that situation? This insult is unacceptable. I just a few days ago stated that i intend to implement SDR within what the community prefers or as a seperate fork. So thats completely the opposit of what i stated [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Please keep in mind we're a public charity using public money from taxpayers, which means we need a criteria for payments and that said payments must be issued objectively. The GA might be able to distribute money with subjective criterias... But not this specific money which is being discussed. I mean, anyone would get mad if their elected officials did that with tax money, so obviously the same will extend here. (Remember the time when an infamous mayor used public money to fix only the roads surrounding his home? Yeah, let's not do this, alright?) If commits are a no-go because FFmpeg has internal governance issues on how those happen, we can think of something else, as long as it retains the objectiveness expected from the use of public money. But we're putting the cart ahead of the horse. Please don't get bogged down by the details, move forward with the scope of work — that's the written version of how STF funds can serve both STF as FFmpeg's purposes. A journey of a thousand miles begins with a single step, if you focus on the future steps you'll trip, fall, and lose the opportunity for the sponsorship. There are only a couple weeks longer to finish the Scope of Work, and that blocks pretty much everything. STF said itself that the other details can be discussed later. Michael: It's not very dissimilar, no. X.Org recently made something similar to Outreachy, the Endless Vacations of Code program (EVoC), if you prefer to make it more similar to that it might be possible. A few things to keep in mind in such a case: The stipend is fixed and agreed beforehand, there are less reports and payments to make, you can only hire in an educational capability (so not the staff you're looking for), it is less suitable for continuous tasks (which was the original issue), and you still need the Scope of Work before it begins. I believe you can actually do both via contracts as via education programs if you wanted, but the latter might be of limited use to you. Att., -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Mon, Jan 29, 2024 at 3:32 PM Kieran Kunhya wrote: > > > On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer > wrote: > >> Hi Kieran >> >> On Sun, Jan 28, 2024 at 08:42:00PM +, Kieran Kunhya wrote: >> > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote: >> > >> > > Both work fine really. For example iam not employed by FFlabs and the >> work >> > >> i did for them is just by sending invoices, while what i do qualifies >> > >> maintenance probably close to 100%. >> > >> >> > > >> > > Fflabs is a private company that can choose however it likes how to >> > > distribute its funds. STF/SPI/FFmpeg are not the same. >> > > >> > > Would you like every invoice you make to be on this mailing list and >> > > discussed in depth in public? And if that invoice was voted against >> by the >> > > GA what would you do? >> > > >> > > Kieran >> > > >> > >> > Remember the outcry about SDR that literally drove people away from the >> > project? Well imagine that for one of your invoices. >> >> Do you mean it would drive them away because of how much or how little i >> work for ? >> Or becuase of what i work for ? >> > > You refused to acknowledge the public outcry over SDR for months and > pushed patches the community clearly objected to (see andreas thread). > > That could clearly apply to invoiced work that the community disagreed > with. What would you do then? You weren't willing to compromise last time > for your hobby, what makes you willing to compromise in that situation? > > I mean it basically happened already with SDR, just without an invoice. > > "I think you should try to bring the work you want funded into the > framework > that they told us to use. Instead of complaining" > > And now you follow the same tactics with Derek. Accusing people of > disagree with you of spreading resentment. > > Kieran > > Sent from my mobile device > ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
>> On 1/28/2024 3:25 AM, Michael Niedermayer wrote: >> As others have said, the whole model of using discrete projects here seems >> opposed to >> the actual intent of the STF - maintained and stable OSS long term. > > The whole suggestion here is based on what STF and SPI said. There was a > conference > between SPI and STF where they worked the details out. > Also all the things SPI told us had STF in CC. What SPI convinced STF is best is not necessarily the same. Also notably missing here is the community (as in, more than just Thilo) having any access to review, comment, or help direct this. > I think you should try to bring the work you want funded into the framework > that they told us to use. Instead of complaining Vibes of "shut up and stop dissenting". Nice. I will not be sending any more replies. >> Furthermore, we *already* have a bunch of money sitting in SPI funds that >> *is* suitable >> for use on discete projects, but it never gets used. It is a poor way to >> encourage useful >> work, IMO. > > Theres a very big difference. we have around 100k USD in SPI > > STF has a lower limit of 150.000 € so we actually need to ask them for > at least 150k to be qualified IIUC > And honestly if you reject that, i just dont understand you. > "Estimated costs: The cost of the work described in the application must > exceed €150,000 (current minimum)." > > AT no point could we have done anything with SPI money in a similar > magnitude. In fact trying to use SPI money for any work failed because of it > not being enough. I have yet to see an actual project of "this magnitude" materialize as a proposal. - Derek ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer wrote: > Hi Kieran > > On Sun, Jan 28, 2024 at 08:42:00PM +, Kieran Kunhya wrote: > > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote: > > > > > Both work fine really. For example iam not employed by FFlabs and the > work > > >> i did for them is just by sending invoices, while what i do qualifies > > >> maintenance probably close to 100%. > > >> > > > > > > Fflabs is a private company that can choose however it likes how to > > > distribute its funds. STF/SPI/FFmpeg are not the same. > > > > > > Would you like every invoice you make to be on this mailing list and > > > discussed in depth in public? And if that invoice was voted against by > the > > > GA what would you do? > > > > > > Kieran > > > > > > > Remember the outcry about SDR that literally drove people away from the > > project? Well imagine that for one of your invoices. > > Do you mean it would drive them away because of how much or how little i > work for ? > Or becuase of what i work for ? > You refused to acknowledge the public outcry over SDR for months and pushed patches the community clearly objected to (see andreas thread). That could clearly apply to invoiced work that the community disagreed with. What would you do then? You weren't willing to compromise last time for your hobby, what makes you willing to compromise in that situation? I mean it basically happened already with SDR, just without an invoice. "I think you should try to bring the work you want funded into the framework that they told us to use. Instead of complaining" And now you follow the same tactics with Derek. Accusing people of disagree with you of spreading resentment. Kieran Sent from my mobile device ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Derek On Mon, Jan 29, 2024 at 02:38:42PM +, Derek Buitenhuis wrote: > On 1/28/2024 3:25 AM, Michael Niedermayer wrote: > > At this point, what we need is a list of Projects so we can submit an > > application to STF > > at or before 12th Feb. (at the 14th they have a meeting and will review our > > submission) > > What STF told us, they need ATM is: > > As others have said, the whole model of using discrete projects here seems > opposed to > the actual intent of the STF - maintained and stable OSS long term. The whole suggestion here is based on what STF and SPI said. There was a conference between SPI and STF where they worked the details out. Also all the things SPI told us had STF in CC. I think you should try to bring the work you want funded into the framework that they told us to use. Instead of complaining > > Furthermore, we *already* have a bunch of money sitting in SPI funds that > *is* suitable > for use on discete projects, but it never gets used. It is a poor way to > encourage useful > work, IMO. Theres a very big difference. we have around 100k USD in SPI STF has a lower limit of 150.000 € so we actually need to ask them for at least 150k to be qualified IIUC And honestly if you reject that, i just dont understand you. "Estimated costs: The cost of the work described in the application must exceed €150,000 (current minimum)." AT no point could we have done anything with SPI money in a similar magnitude. In fact trying to use SPI money for any work failed because of it not being enough. thx [...] -- 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. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 07:43:17PM +0200, Rémi Denis-Courmont wrote: > Le maanantaina 29. tammikuuta 2024, 19.27.14 EET Michael Niedermayer a écrit : > > Also FFmpeg has been part of Google summer of code for many many years > > and also in the past in outreachy. All these projects payed "students" > > for work they did. > > From a legal point of view, these are probably very similar > > > > Mysteriously, there was a total absence of similar drama there. > > I wonder how it could have been possible to do that for over a decade > > with not one instance of drama or problems like here. > > Google funding GSoC students to work on FFmpeg. And nobody objected agains > the > core idea of STF funding developers to work on FFmpeg. > > The "drama" is about how and through whom the funding goes. ok, elaborate please All FFmpeg money has always been handled through SPI or associated entities Its under the control of the community and its transparent and the take 0% fee. And very important what do you propose ? Should we reject the maybe 200k € grant we could get from STF now ? I mean is that really what people suggest here ? Not to mention we will end up with SPI or another similar entity again after long discussions and votes. There is no majority for a intransparent corporate entity. And i was looking for a EU entity similar to SPI myself since a long time Iam sure there are some but i failed to find them. The one we used previously is not usable ATM. Others i found take non zero fees. And again "for profit entities" have opposition > That drama > couldn't be had for GSoC because how was however Google decides, and there > was > no intermediary to go through (money went straight from Google to the > students). SPI handles all the GSoC mentor money. And lets just assume it would handle the students money too, what difference would that really make ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Le maanantaina 29. tammikuuta 2024, 19.27.14 EET Michael Niedermayer a écrit : > Also FFmpeg has been part of Google summer of code for many many years > and also in the past in outreachy. All these projects payed "students" > for work they did. > From a legal point of view, these are probably very similar > > Mysteriously, there was a total absence of similar drama there. > I wonder how it could have been possible to do that for over a decade > with not one instance of drama or problems like here. Google funding GSoC students to work on FFmpeg. And nobody objected agains the core idea of STF funding developers to work on FFmpeg. The "drama" is about how and through whom the funding goes. That drama couldn't be had for GSoC because how was however Google decides, and there was no intermediary to go through (money went straight from Google to the students). -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> > Mysteriously, there was a total absence of similar drama there. > I wonder how it could have been possible to do that for over a decade > with not one instance of drama or problems like here. > > We had students passing the mentors review, being paid but code was > found not be clean enough yet for git master and was not yet merged > I remember no fight about any such case. > There also where the normal cases where students failed to reach the > goal and did not get paid abd code was not merged, and the ones that > succeeded got paid and code was merged. > You clearly forget the HTTP Server project. I reviewed it as 0 and was "politely" asked to change it. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hello Kieran On Mon, Jan 29, 2024 at 03:02:24PM +, Kieran Kunhya wrote: > > > > > > >> [...] the GA definitly cannot object to an invoice for a project that > > the GA approved previously. > > > "The General Assembly is sovereign and legitimate for all its decisions > > regarding the FFmpeg project." > > > > When working with a contract (and a SOW), the General Assembly won't be > > able to block an invoice. > > Because the General Assembly will already have exercised its sovereignty > > before the work started. > > And unless the GA becomes a nation, any court of law would uphold the > > contract. > > > > In this project, acceptance of a patch is based on the technical contents > of a patch, not a few vague paragraphs in a SoW. These decisions are made > by the Technical Committee and the General Assembly. > > Tying the project contractually is unacceptable. "the FFmpeg project" is not a legal entity, so thats probably not even possible if one wanted. Also FFmpeg has been part of Google summer of code for many many years and also in the past in outreachy. All these projects payed "students" for work they did. From a legal point of view, these are probably very similar Mysteriously, there was a total absence of similar drama there. I wonder how it could have been possible to do that for over a decade with not one instance of drama or problems like here. We had students passing the mentors review, being paid but code was found not be clean enough yet for git master and was not yet merged I remember no fight about any such case. There also where the normal cases where students failed to reach the goal and did not get paid abd code was not merged, and the ones that succeeded got paid and code was merged. > There are plenty of "corporate" open source projects where this is fine, > but there is a reason we are not one of those full of corporate friendly > code like binary blobs, intrinsics, SDKs etc. Iam glad there is one thing we agree on :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> This is also why there's no need to review the invoices, and no risk of a > legitimate invoice being rejected: Because the deliverable will likely be > the commit (unless the GA objects beforehand and asks SPI to use something > else), so until it (the MR/PR) is accepted, there's no invoice to start > with. And as STF is footing the bill, there's no reason to FFmpeg concern > itself if it turned out expensive or not when reviewing, and can focus in > actually improving the program (SPI and STF will place some budget limits, > so contributors/contractors know what to expect and the money won't run > out). > Of course we need to be concerned about this, FFmpeg isn't a think tank for people's fun developments with public money from STF. The same applies to donated funds, we have a responsibility as a community to spend the money for community purposes. You're not doing SPI any favours here with these comments. Kieran On Mon, Jan 29, 2024, 12:02 Kieran Kunhya wrote: > >> >>> >> [...] the GA definitly cannot object to an invoice for a project that >>> the GA approved previously. >>> > "The General Assembly is sovereign and legitimate for all its >>> decisions regarding the FFmpeg project." >>> >>> When working with a contract (and a SOW), the General Assembly won't be >>> able to block an invoice. >>> Because the General Assembly will already have exercised its sovereignty >>> before the work started. >>> And unless the GA becomes a nation, any court of law would uphold the >>> contract. >>> >> >> In this project, acceptance of a patch is based on the technical contents >> of a patch, not a few vague paragraphs in a SoW. These decisions are made >> by the Technical Committee and the General Assembly. >> >> Tying the project contractually is unacceptable. >> >> There are plenty of "corporate" open source projects where this is fine, >> but there is a reason we are not one of those full of corporate friendly >> code like binary blobs, intrinsics, SDKs etc. >> >> Kieran >> >>> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Again, this sounds like a misunderstanding.
The SOW is subservient to the merge, not the other way around. In other
words, the SOW don't require you to merge, but when/if you do merge, then
the SOW will require the payment to the contractor, which SPI handles. So
the SOW makes clear that if FFmpeg refuses to merge, there'll be no payment.
This is also why there's no need to review the invoices, and no risk of a
legitimate invoice being rejected: Because the deliverable will likely be
the commit (unless the GA objects beforehand and asks SPI to use something
else), so until it (the MR/PR) is accepted, there's no invoice to start
with. And as STF is footing the bill, there's no reason to FFmpeg concern
itself if it turned out expensive or not when reviewing, and can focus in
actually improving the program (SPI and STF will place some budget limits,
so contributors/contractors know what to expect and the money won't run
out).
The goal of the SOW (and of having SPI onboard) is to allow the GA to focus
on stuff actually relevant to FFmpeg (like what's going to be merged) and
delegate the worldly concerns like payments and contracts to SPI. Who is
signing the contracts (and thus being bound and tied to it) is SPI.
This is why it sounds a lot like a misunderstanding. What is actually
required from the GA is what the GA does — managing and leading FFmpeg.
That means deciding aspects which SPI cannot and will not decide for you,
like the scope of work ("what do you want done and sponsored by STF?"), and
what SPI cannot answer for you (such as how FFmpeg does things).
Do note that if someone do a MR/PR and then the technical committee or the
GA refuse to merge, without a SOW, almost every court (in the US or in
Germany) will force FFmpeg to pay not only the invoice but also the legal
costs. That would be unacceptable for SPI, as it puts other projects in
risk as well. We must kindly request that FFmpeg's General Assembly avoid
such dangerous behavior.
Feel free to make any other questions you may have,
Att.,
Jonatas L. Nogueira (“Jesusalva”)
SPI Board of Directors
On Mon, Jan 29, 2024, 12:02 Kieran Kunhya wrote:
>
>> >> [...] the GA definitly cannot object to an invoice for a project that
>> the GA approved previously.
>> > "The General Assembly is sovereign and legitimate for all its decisions
>> regarding the FFmpeg project."
>>
>> When working with a contract (and a SOW), the General Assembly won't be
>> able to block an invoice.
>> Because the General Assembly will already have exercised its sovereignty
>> before the work started.
>> And unless the GA becomes a nation, any court of law would uphold the
>> contract.
>>
>
> In this project, acceptance of a patch is based on the technical contents
> of a patch, not a few vague paragraphs in a SoW. These decisions are made
> by the Technical Committee and the General Assembly.
>
> Tying the project contractually is unacceptable.
>
> There are plenty of "corporate" open source projects where this is fine,
> but there is a reason we are not one of those full of corporate friendly
> code like binary blobs, intrinsics, SDKs etc.
>
> Kieran
>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
On 1/29/2024 3:02 PM, Kieran Kunhya wrote: > In this project, acceptance of a patch is based on the technical contents > of a patch, not a few vague paragraphs in a SoW. These decisions are made > by the Technical Committee and the General Assembly. > > Tying the project contractually is unacceptable. Who even has the legal authority to force an open source project to push code? We will reject bad code, and the person or entity who agreed to such a contract will be the one with an issue. - Derek ___ 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".
