[FFmpeg-devel] Sovereign Tech Fund

[FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4183 bytes --]

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)
What STF told us, they need ATM is:

- A scope of work for the project to defined before hand for the upcoming review and eventually a contract. It doesn’t have to be tied to specific people.
- The contract STF will sign with SPI will be a service agreement based on that SOW and milestones. Payment of invoices will be contingent and after delivery (aka performance) of agreed upon milestones.

My suggestion is that we create a Trac WIKI page similar to the ideas
page for GSoC.
On that page everyone can add a project idea.
The requirement is that
1. it must fit in the goals and mission and all of STF
2. it must be about FFmpeg (IIUC non coding tasks are ok)
3. it must have a developer willing to do the work and a monetary
   amount as well as a expected time frame. Of course these don't need to
   be added at the same time you can add an idea and someone else can
   add herself as person doing the work.
   But for consideration it needs to contain all parts
4. The developer doing the work must be qualified. An easy way to ensure
   this, is that (s)he has at least 100 authored commits in FFmpeg.

According to STF, April 1st is a possible start date for the work and STF would
also like to know if the work will be finished in 2024 or 2025 for their
budget.
the SoW can be for example:
"do X by date Y to receive Z", but according to SPI it can also be
"only tasks X are eligible, invoices should be sent by date Y, and payment
 will not exceed the budget Z"
"Ideally, it should also mention the
 parameters for how much each thing done is worth — eg. If you're paying for
 hours or for tasks, and how much — as the SOW is supposed to give the
 contracted person means to know how much they'll be paid for what they do."
"SOW should also note that if no valid tasks are performed, no
 payment will be made."

Next step. For each Project suggestion from the wiki page we will send
a mail to the ML with a copy and paste of the project suggestion.
Once an apparent consensus is reached.

This is the communities opportunity to object or approve the suggestion.
Anyone can call for a formal vote of the GA here too if they do not want
to object/approve in public. But i hope we can avoid that overhead.

All suggested project ideas will then be submitted to STF

We have never done STF before so there likely will be some surprises
and we may need to adjust in case we hit any issues.

and I also didn't expect to be involved in this but i don't want to stand
around and have the opportunity for FFmpeg lost

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!

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)

Thanks
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Sun, 28 Jan 2024 at 03:26, Michael Niedermayer <michael@niedermayer.cc>
wrote:

> 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)
> What STF told us, they need ATM is:
>
> - A scope of work for the project to defined before hand for the upcoming
> review and eventually a contract. It doesn’t have to be tied to specific
> people.
> - The contract STF will sign with SPI will be a service agreement based on
> that SOW and milestones. Payment of invoices will be contingent and after
> delivery (aka performance) of agreed upon milestones.
>
> My suggestion is that we create a Trac WIKI page similar to the ideas
> page for GSoC.


" To receive funding from the Sovereign Tech Fund, technologies must be
under-supplied or threatened by other circumstances, acute or long-term,
such as market consolidation or severe dependencies. The lack of support
and resources or technical alternatives places the technologies in a
vulnerable state that threatens the existence and sustainability of the
project."

I read that as STF is there to support maintenance of open source projects,
not just another GSoC wishlist.

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.

Regards,
Kieran Kunhya
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3422 bytes --]

Hi Kieran

Iam adding Jonatas to the CC, as he suggested the SoW framework for everything.
Maybe he can clarify it.

more reply from me at the end

On Sun, Jan 28, 2024 at 03:54:20PM +0000, Kieran Kunhya wrote:
> On Sun, 28 Jan 2024 at 03:26, Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > 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)
> > What STF told us, they need ATM is:
> >
> > - A scope of work for the project to defined before hand for the upcoming
> > review and eventually a contract. It doesn’t have to be tied to specific
> > people.
> > - The contract STF will sign with SPI will be a service agreement based on
> > that SOW and milestones. Payment of invoices will be contingent and after
> > delivery (aka performance) of agreed upon milestones.
> >
> > My suggestion is that we create a Trac WIKI page similar to the ideas
> > page for GSoC.
> 
> 
> " To receive funding from the Sovereign Tech Fund, technologies must be
> under-supplied or threatened by other circumstances, acute or long-term,
> such as market consolidation or severe dependencies. The lack of support
> and resources or technical alternatives places the technologies in a
> vulnerable state that threatens the existence and sustainability of the
> project."
> 
> I read that as STF is there to support maintenance of open source projects,
> not just another GSoC wishlist.
> 

> 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.

Yes, thats also how i understand it.
Also ongoing maintenance or various things, infrastructure work and so
on possibly.
Maybe a case would also be our fuzzer coverage is broken since forever
as googles constraints on disk and timeout dont allow it. This is
something that would require a dedicated effort to investigate possible
solutions.


> Statements of Work and milestones (by definition) are for features.

The SoW suggestion/need came from a lawyer that jonatas asked IIUC.
so i can just suggest to put work like what you list above into a SOW like
framework. Or maybe Jonatas can clarify, in case i misunderstood

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

>
> > Statements of Work and milestones (by definition) are for features.
>
> The SoW suggestion/need came from a lawyer that jonatas asked IIUC.
> so i can just suggest to put work like what you list above into a SOW like
> framework. Or maybe Jonatas can clarify, in case i misunderstood
>

My point is that ongoing maintenance can't be split into discrete pieces of
work, nor arguably can a given timescale be associated with cleanup.
For example YUVJ is difficult, until you remove it and see the bugs you
don't know how long it will take. This is not suited to the bounty/SoW
methodology.

We don't need STF to be funding features, we need maintenance,
infrastructure etc which all lends itself to salaried 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

That's not a problem at all; because you can divide the work into discrete
pieces after it's done (on the invoice), just like liberal professionals
(eg. accountants, lawyers, administrators, etc.)

The SOW defines what is acceptable on the invoice (so in the YUVJ case, for
example, it could be "code related to YUVJ implementation and bugs arising
of it, as well as review of the PRs/MRs associated with it, but not tagging
issue tickets, duplicated work or code formatting" — I have no idea, this
is just for inspiration), as well as the timeframes by when they should
submit the invoices (and if they need to submit any other proof of their
work, what and when). It should also define how payment works (typically by
hour or by code line, there's some leeway here though), what's the maximum
budget (specially if the metric is exploitable), the value of which unit of
work (defined before) which must not be above the market price.

Contributors are not employees, they don't need to login at 8 and logout at
17 for a fixed wage. In fact, they might not do anything and thus no money
be due to them at all. That's why we make a SOW, it makes clear what they
can do, how much they can earn, what will not be paid (usually unrelated
work) even if they do, and by when they should submit invoices and
evidences of the work they did to receive payment.

Do say if there are still questions, I'll be happy to answer and help here.

Regards,

Jonatas L. Nogueira (“Jesusalva”)

On Sun, Jan 28, 2024, 15:59 Kieran Kunhya <kierank@obe.tv> wrote:

> > Statements of Work and milestones (by definition) are for features.
>>
>> The SoW suggestion/need came from a lawyer that jonatas asked IIUC.
>> so i can just suggest to put work like what you list above into a SOW like
>> framework. Or maybe Jonatas can clarify, in case i misunderstood
>>
>
> My point is that ongoing maintenance can't be split into discrete pieces
> of work, nor arguably can a given timescale be associated with cleanup.
> For example YUVJ is difficult, until you remove it and see the bugs you
> don't know how long it will take. This is not suited to the bounty/SoW
> methodology.
>
> We don't need STF to be funding features, we need maintenance,
> infrastructure etc which all lends itself to salaried 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

Note: I have no idea what YUVJ is (I assume you want to remove it, not to
implement it?) and I forgot to mention "reverted work" (likely in the form
"work not yet merged or reverted within 30 days after being merged"). The
goal here was to make easier to understand what's expected.

Of course, I can help with legalese if you explain to me and review it
afterwards, just let me know in such case.

Att.

Jonatas L. Nogueira (“Jesusalva”)

On Sun, Jan 28, 2024, 16:20 Jonatas L. Nogueira <jesusalva@spi-inc.org>
wrote:

> That's not a problem at all; because you can divide the work into discrete
> pieces after it's done (on the invoice), just like liberal professionals
> (eg. accountants, lawyers, administrators, etc.)
>
> The SOW defines what is acceptable on the invoice (so in the YUVJ case,
> for example, it could be "code related to YUVJ implementation and bugs
> arising of it, as well as review of the PRs/MRs associated with it, but not
> tagging issue tickets, duplicated work or code formatting" — I have no
> idea, this is just for inspiration), as well as the timeframes by when they
> should submit the invoices (and if they need to submit any other proof of
> their work, what and when). It should also define how payment works
> (typically by hour or by code line, there's some leeway here though),
> what's the maximum budget (specially if the metric is exploitable), the
> value of which unit of work (defined before) which must not be above the
> market price.
>
> Contributors are not employees, they don't need to login at 8 and logout
> at 17 for a fixed wage. In fact, they might not do anything and thus no
> money be due to them at all. That's why we make a SOW, it makes clear what
> they can do, how much they can earn, what will not be paid (usually
> unrelated work) even if they do, and by when they should submit invoices
> and evidences of the work they did to receive payment.
>
> Do say if there are still questions, I'll be happy to answer and help here.
>
> Regards,
>
> Jonatas L. Nogueira (“Jesusalva”)
>
> On Sun, Jan 28, 2024, 15:59 Kieran Kunhya <kierank@obe.tv> wrote:
>
>> > Statements of Work and milestones (by definition) are for features.
>>>
>>> The SoW suggestion/need came from a lawyer that jonatas asked IIUC.
>>> so i can just suggest to put work like what you list above into a SOW
>>> like
>>> framework. Or maybe Jonatas can clarify, in case i misunderstood
>>>
>>
>> My point is that ongoing maintenance can't be split into discrete pieces
>> of work, nor arguably can a given timescale be associated with cleanup.
>> For example YUVJ is difficult, until you remove it and see the bugs you
>> don't know how long it will take. This is not suited to the bounty/SoW
>> methodology.
>>
>> We don't need STF to be funding features, we need maintenance,
>> infrastructure etc which all lends itself to salaried 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Sun, 28 Jan 2024 at 19:20, Jonatas L. Nogueira <jesusalva@spi-inc.org>
wrote:

> That's not a problem at all; because you can divide the work into discrete
> pieces after it's done (on the invoice), just like liberal professionals
> (eg. accountants, lawyers, administrators, etc.)
>

As an open source project we can't give developers de-facto unbounded time
to work on something. It's not the same as accountants and lawyers. They
know roughly how long a set of accounts or a legal operation will take from
experience. These changes are one-off.

Many of the maintenance projects in FFmpeg can't be easily split up into
the simple examples you provide. FFmpeg is hugely coupled, one change in
code like YUVJ affects a lot of unrelated things. It's not at all easy to
cost this work.

The threading changes took the best part of a year and are still ongoing.
This does not lend itself well to SoW/bounties.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 3918 bytes --]

While it's true a traditional SOW breaks work into milestones, we're going
for a simplified one here out of need. Think on when you ask for
consulting, not when you ask for a feature. You should not assume we want
to write eg. "Finish removing YUVJ by date X" ─ that's not the plan and as
you said it makes no sense (even less when you consider the SOW are
individual agreements, and we're likely going to have multiple people
working on it).

The timeframes aren't "finish X by Y", they're "report what you did by date
Y". In a sense, the report is the actual deliverable.

The Scope of Work isn't "only touch X", but the conditions on which payment
is acceptable (or not). As you said, the sponsorship is for maintenance
work, so it should make clear that features aren't eligible (on that SOW at
least). Otherwise, someone could make a feature nobody asked for, even less
needs it, and want to be paid for it. Or find some busywork which doesn't
help in the slightest and come wanting money. So if you had to refactor a
whole code because you're working on X, that's fine, but if you decide to
refactor the code because you think it's ugly and wanted to refactor it
then it might not be what you want to pay for. Or maybe you want,
refactoring can improve code readability and no one normally does that. I'm
not writing the scope, you are, I at most convert it to legalese when/if
required.

No one is getting paid for signing a contract and merry be merry, and it's
not acceptable to just give money "as we deem fit" (just think of all the
possible complaints and hours you'll waste with people questioning why you
paid more for A than for B). That would be poor governance, I also doubt
STF would be willing to sponsor if there's not even a scope of work.

I am attaching a quick example draft (actually a mockup) I made just now in
hopes to make it easier to visualize what is expected from the SOW. ****This
is not for review, it is for illustration purposes.*** *It is a quick
draft/mockup with random information written under a hour just for
visualization, and will not be used when the actual SOW is prepared, I just
wanted to make it easier to see what I'm thinking about for the SOW.

The first thing to prepare is section 2 (Scope of Work), as we need to
report it to STF beforehand. It is what STF is (or is not) willing to pay
for, and by consequence what FFMPEG is (or is not) willing to pay for. It
is the priority, as there *is* a deadline to finish it and deliver it to
STF (Feb 12th). Of course, it probably could have said "tasks with a
'maint' label on the issue tracker" or whatever, it's not like I ran this
mockup by a legal counsel nor anything.

Section 3 and 4 will likely later be required by STF as they have to do
their own audit, but this likely can be delayed for after the grant is
approved. It also seems to be somewhat controversial at the moment, so I
suggest that instead of straying into heated debates over publicity of the
invoices, conflicts of interest and whatnot, we focus on securing the
funding first (which means the first page of the mockup). After we have a
solid scope of work to present to STF, we can worry about how the funds
will be distributed (the mockup is hour-based and monthly, but as I said,
there are other ways to distribute them) and how the approval process will
go. (And in theory, the person could provide their own hourly rate,
although I see no reason why anyone would do so).

Again, I'm available to answer any questions you may have.
And on that note: I believe the same as Michael regarding OFAC restriction
as unlike Russia or North Korea, there is no ban against China residents,
but we can ask the legal counsel on the specific cases if the need arises.

Regards,

--
Jonatas L. Nogueira (“jesusalva”)
Board of Directors Member
Software in the Public Interest, Inc.

[-- Attachment #2: Example SOW for FFMPEG.pdf --]
[-- Type: application/pdf, Size: 74260 bytes --]

[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Sun, 28 Jan 2024 at 21:19, Jonatas L. Nogueira <jesusalva@spi-inc.org>
wrote:

> While it's true a traditional SOW breaks work into milestones, we're going
> for a simplified one here out of need. Think on when you ask for
> consulting, not when you ask for a feature. You should not assume we want
> to write eg. "Finish removing YUVJ by date X" ─ that's not the plan and as
> you said it makes no sense (even less when you consider the SOW are
> individual agreements, and we're likely going to have multiple people
> working on it).
>

You misunderstand this community. There are disagreements going on for
decades. Unless it's a black and white delivery of a feature, this will
never fly in FFmpeg.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2716 bytes --]

Hi Kieran

On Sun, Jan 28, 2024 at 06:59:22PM +0000, Kieran Kunhya wrote:
> >
> > > Statements of Work and milestones (by definition) are for features.
> >
> > The SoW suggestion/need came from a lawyer that jonatas asked IIUC.
> > so i can just suggest to put work like what you list above into a SOW like
> > framework. Or maybe Jonatas can clarify, in case i misunderstood
> >
> 
> My point is that ongoing maintenance can't be split into discrete pieces of
> work, nor arguably can a given timescale be associated with cleanup.

Well, i certainly can split alot of the  maintenance I do in discrete pieces of
work I would assume at least some people can do that too for their work.


> For example YUVJ is difficult, until you remove it and see the bugs you
> don't know how long it will take. This is not suited to the bounty/SoW
> methodology.

I think the question is more, if this is suited for STF then.
Because if its so unclear and open endeded iam not sure STF would be willing
to fund it.
I think the SoW side would not be the obstacle, but this is more for Tara and
Jonatas to awnser than me.
You can maybe write in a SoW along the lines of
Remove YUVJ without introducing regressions, within 18 months and upto 50k EUR
and payment would be 80USD per hour.
You would have to keep track of the time spend in accordance to legal requirements

OTOH if you cannot give any time or monetary limit at all i do not think STF
would sponsor this. So i dont think the SoW or SPI is the obstacle here.

Also it has to be said, that the example is hypothetical, you are not going to
do that work. You seem more interrested in arguing against anything related to SPI
(which you also did in the last refund request from lynne until lynne droped
the request for parts to repair her laptop)
But that said iam very interrested in your oppinon and input, if it leads to
improvments.


> 
> We don't need STF to be funding features, we need maintenance,

Well i think we are happy about all funding, but STF is more about maintenance


> infrastructure etc which all lends itself to salaried work.

employment & salary is one way to pay someone. Sending invoices and doing
some paperwork before is the other.

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 as
maintenance probably close to 100%.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

>
> Also it has to be said, that the example is hypothetical, you are not
> going to
> do that work. You seem more interrested in arguing against anything
> related to SPI
>

This is a completely false accusation. I have no issues with SPI as an
organisation. The hardware I bought and host was reimbursed promptly and
efficiently by SPI.

I find the attacks (to coin your favourite word) unacceptable.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

> > infrastructure etc which all lends itself to salaried work.
>
> employment & salary is one way to pay someone. Sending invoices and doing
> some paperwork before is the other.
>
> 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 as
> maintenance probably close to 100%.
>

As Remi says this is not true, bounties are suitable more for discrete
features and employment more for maintenance.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

>
> 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

>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> 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.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1748 bytes --]

Hi Kieran

On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:
> On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> 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 ?

I do somewhere have an invoice from a porn related company i should search for that
and post it :)
but iam not sure i can without that company agreeing too.

BUT let me try to return to the topic even if its more fun not to.

We have an opertunity here to have some FFmpeg work payed by STF/SPI
and we should try to use this oppertunity to pay some FFmpeg developers.
Iam sure neither STF nor SPI will mind if we reject all the money. But I
dont think thats a very wise choice, so lets rather work towards making
a list of projects, agreeing to them and submitting an application to STF
before the deadline feb ~ 12th

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi Kieran
>
> On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:
> > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <kierank@obe.tv> wrote:

>
>
> On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
>> Hi Kieran
>>
>> On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:
>> > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2557 bytes --]

Hi Kieran

On Mon, Jan 29, 2024 at 06:31:30PM +0000, Kieran Kunhya wrote:
> On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > Hi Kieran
> >
> > On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:
> > > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Mon, 29 Jan 2024, 18:54 Michael Niedermayer, <michael@niedermayer.cc>
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1680 bytes --]

On Mon, Jan 29, 2024 at 07:02:57PM +0000, Kieran Kunhya wrote:
> On Mon, 29 Jan 2024, 18:54 Michael Niedermayer, <michael@niedermayer.cc>
> 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

>
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Tomas Härdin]

mån 2024-01-29 klockan 21:04 +0100 skrev Michael Niedermayer:
> On Mon, Jan 29, 2024 at 07:02:57PM +0000, Kieran Kunhya wrote:
> > On Mon, 29 Jan 2024, 18:54 Michael Niedermayer,
> > <michael@niedermayer.cc>
> > 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2143 bytes --]

Hi Kieran

On Sun, Jan 28, 2024 at 08:37:17PM +0000, 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.

yes, so can microsoft, google, any many others


> STF/SPI/FFmpeg are not the same.

yes, they are transparent publically funded, open, ...


> 
> Would you like every invoice you make to be on this mailing list and
> discussed in depth in public?

If it provides entertainment to someone, honestly, i dont care much

_BUT_: Thats not implied by SPI/STF here
anyone can propose a project under a pseudonym. I belive she would
have to provide her real name to SPI & STF but not on the ML and WIKI

even with refund requests, I think some people have used pseudonyms
so if someone wants some privacy, it can be done. Maybe not 100%
against a sophisticated attacker but being employed certainly doesnt
provide that either.


> And if that invoice was voted against by the
> GA what would you do?

I would cry ;)

seriously, I have said very clearly in my first mail that there can be NO late
objections to a STF/SPI Project. objections must be before its submitted to
STF. So theres no way the GA could object to an invoice, the GA could object to
the project before its started only

I do remember this concern from you and the FFlabs CEO.
thats why i made sure that this case would not be possible. So no the GA
definitly cannot object to an invoice for a project that the GA approved
previously. That said I do not belive the GA (which is made of adult intelligent
humans) would block an invoice for a project that was previously approved.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

> I would cry ;)
>
> seriously, I have said very clearly in my first mail that there can be NO
> late
> objections to a STF/SPI Project. objections must be before its submitted to
> STF. So theres no way the GA could object to an invoice, the GA could
> object to
> the project before its started only
>
> I do remember this concern from you and the FFlabs CEO.
> thats why i made sure that this case would not be possible. So no the GA
> definitly cannot object to an invoice for a project that the GA approved
> previously. That said I do not belive the GA (which is made of adult
> intelligent
> humans) would block an invoice for a project that was previously approved.
>

"The General Assembly is sovereign and legitimate for all its decisions
regarding the FFmpeg project."

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

Keep in mind I only receive messages if I'm explicitly in the To field. I'm
with only half of the context, so my
messages may sound weird, out of context, repetitive, etc. In any case.


>> [...] 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.

So the first statement which I have no context of would be correct with
SPI's approach;
the GA would not (realistically) be able to object to the invoice, unless
it is in breach of the contract/SOW.

(But if it is in breach of the contract or the SOW, then SPI will refuse to
pay anyway).


> You misunderstand this community. There are disagreements going on for
decades.

I've worked with worse.
FFmpeg asked to divide the work in milestones, so focus on where you agree
with.
Whatever there's disagreement, you can always apply later for more funding.
(At least from what I've understood).

For example, everyone can agree improving code readability is a good thing,
even if not how.
That's a good start. Ask for funding for it. The "how" can be done later
(see the PS).


> 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?

There's no need for that, you know?
One of the reasons to have a SOW is exactly to avoid such fights.
After all, the scope of work is decided before (and you need to do this
anyway, to ask for STF funding).
In an ideal scenario, invoices only need to be checked for legitimacy ─ if
the issuer is the one who worked, if the work is on the scope, if the time
spent isn't absurd, etc.
So there would be no need for the whole assembly to involve itself, unless
it's an appeal.
But of course, if you want every invoice there, it likely can be done, as
long that privacy laws are observed.


> I am sure neither STF nor SPI will mind if we reject all the money.

SPI is a public charity, so if you want to reject the money, that is not
our problem.
We're here to support you if you do decide to accept, though.
SPI handles non-technical administrative tasks, after all.

Do keep in mind that SPI acts as a fiscal sponsor.
This means that we're taking care of all the paperwork involved, but also
assuming the risks.
So if e.g. some payment is improperly documented and must be returned, SPI
has the duty to return it.

You can do it with some other entity ─ SPI is a public charity, we honestly
don't mind ─ but do keep in mind
that if you don't document everything adequately, SPI will not be held
responsible if it didn't pass by SPI.


> lets rather work towards making a list of projects, agreeing to them and
submitting an application to STF

This is pretty much the Scope of Work, and that would account for half of a
SOW (and also the most
important part of it). One of the reasons why SPI insists on doing the SOW
is because we concluded it
would present better governance (so less risks for you, for STF, for SPI
and for the contributors) and
that it would be expedient to do (as you're already going to do the upper
half when asking the funding).

The bottom part (schedule, deliverables and payment) do need your input on
what works best for FFmpeg,
but ultimately it is mostly operational guidelines expected from
contributors and SPI alike.

*When do you want contributors to report their work, and how?*
*How will the due amount be calculated? When should the invoice be sent?
When should it be paid?*

That's pretty much what's required to fill out the proposed SOW.

If you cannot get a scope of work, you definitely cannot get funding (and
if you get funding, then
what you used is most likely an acceptable scope of work, so it likely
won't need changes either).
If you cannot decide the other details, then odds of being required to
return the money are high.

Asking for a SOW might sound like asking for a lot of work, but it is
paperwork, and you can count
on SPI to do paperwork for you. But SPI acts on your behalf (and never you
on SPI's behalf), so
you do need to instruct us on how you want it to look like. "How can SPI
and the contractor know that
something on the invoice is (in)adequate?" That's the sort of thing the
bottom of the SOW worries about.

And I already said this earlier, but the bottom part is not important right
now.
Securing funding and the scope of work take precedence.
In the worst case, we can just ask our attorney to draft the SOW
altogether. He'll make a few questions,
you answer them, and we use whatever comes out of that.

SPI is here so paperwork doesn't block you, and if paperwork does block
you, then SPI will not be doing
a very good job, right?


PS. in the code refactoring example, usually whatever procedure you use to
transform a PR/MR into a commit is ideal.
I like using commits as deliverables because most projects have all their
internal governance set before it is merged.
So when it becomes a commit (on master branch), it means the project as a
whole already agreed with it.
I'm not sure how FFmpeg does this, though, that's a problem for you to
figure out and not for an outsider to intervene.


Also, sorry if I'm seen to be overstepping my bounds here.
I, as well as the whole SPI Board, wish you to succeed.
However, I admit my enthusiasm might have gotten the best of me in some
earlier messages.
That aside, I do hope the SOW is slightly more clear and easier to
understand now.

--
Jonatas L. Nogueira (“jesusalva”)
Board of Directors Member
Software in the Public Interest, Inc.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

On 1/29/2024 2:26 AM, Jonatas L. Nogueira via ffmpeg-devel wrote:
> Because the General Assembly will already have exercised its sovereignty
> before the work started.

The contract needs to be shared with the GA for it to be able to actually
exercise its sovereignty.

Frankly this all seems pretty 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

>
>
> >> [...] 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <kierank@obe.tv> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

> 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 <kierank@obe.tv> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2394 bytes --]

Hello Kieran

On Mon, Jan 29, 2024 at 03:02:24PM +0000, 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

>
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2099 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3263 bytes --]

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"

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

Le 30 janvier 2024 00:43:39 GMT+02:00, Michael Niedermayer <michael@niedermayer.cc> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1165 bytes --]

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 <michael@niedermayer.cc> 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2411 bytes --]

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 <michael@niedermayer.cc> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Cosmin Stejerean via ffmpeg-devel]

> On Jan 28, 2024, at 7:54 AM, Kieran Kunhya <kierank@obe.tv> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

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 <kierank@obe.tv> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Nicolas George]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Tue, 30 Jan 2024 at 10:12, Nicolas George <george@nsup.org> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Nicolas George]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Tue, 30 Jan 2024 at 10:31, Nicolas George <george@nsup.org> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Nicolas George]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Tue, 30 Jan 2024 at 10:46, Nicolas George <george@nsup.org> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

Le sunnuntaina 28. tammikuuta 2024, 5.25.49 EET Michael Niedermayer a écrit :
> 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.

As anybody who's been following FFmpeg-devel knows, people have pointed out 
SPI seems like a poor choice of vehicle for that sort of commission. I won't 
repeat the arguments that were already made in the second half of last year.

But I will add a few comments...

> Everyone willing to benefit from this sponsorship must not be a US sanctioned
> entity or in a US sanctioned country. 

In other words, the choice of a US vehicle is excluding people who are, or 
fear that they may be affected by US sanctions. Some active developers are 
associated with, for example, the Chinese Academy of Science, Huawei 
Technologies or other Chinese IT R&D entites. This is discriminatory, and thus 
something that an open-source project should actively seek to *avoid*.

German government funding should go to German or at least EU-based entities if 
only for that reason. In other words, by going through SPI, Thilo is 
*unnecessarily* bringing ugly politics into an open-source project. (And 
please don't shoot the messenger here.)

> 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:

The "selection criteria" seem rather restrictive. It seems that critical tasks 
such as long-term maintainance (Anton) and security fixes (you) are in scope. 
Though I can only agree with Kieran that SoW is ill-suited for tasks of the 
sort. If SPI insists on SoW, which is somewhat understandable from their legal 
and moral standpoint, then that is another reason why SPI should not, or 
maybe, cannot, be the vehicle.

By stretching the criteria a little, maybe reasonably expected external or 
normative updates are also in scope, like say implementing optimisations for 
new ISA extensions or new codec profiles. But implementing entirely new 
features seems unambiguously excluded, especially if competing with existing 
open-source projects. Prototypes are also *explicitly* excluded. So for the 
sake of the argument, reimplementing X264, dav1d or GNU/radio functionality in 
FFmpeg seems like it would not qualify.

I am not a lawyer, but there may be nontrivial legal implications for SPI and 
the contractees here. Note that I do not mean to argue against the 
restrictions here. They make perfect sense considering that this funding would 
ultimately come from the German tax payers.

(...)

> My suggestion is that we create a Trac WIKI page similar to the ideas
> page for GSoC.
> On that page everyone can add a project idea.
> The requirement is that
> 1. it must fit in the goals and mission and all of STF
> 2. it must be about FFmpeg (IIUC non coding tasks are ok)

IIUC, they are *not* OK, unless they are a dependency of a coding task:

| Development is our primary focus, although security audits, conference
| attendance, and other community-based events can be included in the
| application should they be necessary.

-- 
レミ・デニ-クールモン
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 5327 bytes --]

Hi Remi, Jonatas (for the sanctioned list question)

On Sun, Jan 28, 2024 at 09:17:03PM +0200, Rémi Denis-Courmont wrote:
> Le sunnuntaina 28. tammikuuta 2024, 5.25.49 EET Michael Niedermayer a écrit :
> > 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.
> 
> As anybody who's been following FFmpeg-devel knows, people have pointed out 
> SPI seems like a poor choice of vehicle for that sort of commission. I won't 
> repeat the arguments that were already made in the second half of last year.

I have seen people associated with commercial entities (FFlabs and Videolabs)
being against SPI.
Given that FFlabs tried to obtain money from STF there is significant conflict
of interrest here.
At least thats how it looks to me.

Of course thats no reason to dismiss any arguments, its just some background not
everyone might be aware of


> 
> But I will add a few comments...
> 
> > Everyone willing to benefit from this sponsorship must not be a US sanctioned
> > entity or in a US sanctioned country. 
> 
> In other words, the choice of a US vehicle is excluding people who are, or 
> fear that they may be affected by US sanctions. Some active developers are 
> associated with, for example, the Chinese Academy of Science, Huawei 
> Technologies or other Chinese IT R&D entites. This is discriminatory, and thus 
> something that an open-source project should actively seek to *avoid*.

There are a few things here.
First we dont sponsor huawei or another company, and iam also sure STF would not
approve that.
Paying some employee of huawei or member of the Chinese Academy of Science
IIUC would only be a problem if that person is personally on the sanctions list.
which you can check here:
https://sanctionssearch.ofac.treas.gov/
But maybe Jonatas can confirm?

Also i iam not sure germany/STF is ok with funding people on the OFAC list
(they technically maybe should not care but i still would not assert that
 as a given)


[...]
>
> > 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:
> 
> The "selection criteria" seem rather restrictive. It seems that critical tasks 
> such as long-term maintainance (Anton) and security fixes (you) are in scope. 
> Though I can only agree with Kieran that SoW is ill-suited for tasks of the 
> sort. If SPI insists on SoW, which is somewhat understandable from their legal 
> and moral standpoint, then that is another reason why SPI should not, or 
> maybe, cannot, be the vehicle.
> 
> By stretching the criteria a little, maybe reasonably expected external or 
> normative updates are also in scope, like say implementing optimisations for 
> new ISA extensions or new codec profiles. But implementing entirely new 
> features seems unambiguously excluded, especially if competing with existing 
> open-source projects. Prototypes are also *explicitly* excluded. So for the 
> sake of the argument, reimplementing X264, dav1d or GNU/radio functionality in 
> FFmpeg seems like it would not qualify.
> 
> I am not a lawyer, but there may be nontrivial legal implications for SPI and 
> the contractees here. Note that I do not mean to argue against the 
> restrictions here. They make perfect sense considering that this funding would 
> ultimately come from the German tax payers.
> 
> (...)
> 
> > My suggestion is that we create a Trac WIKI page similar to the ideas
> > page for GSoC.
> > On that page everyone can add a project idea.
> > The requirement is that
> > 1. it must fit in the goals and mission and all of STF
> > 2. it must be about FFmpeg (IIUC non coding tasks are ok)
> 
> IIUC, they are *not* OK, unless they are a dependency of a coding task:
> 
> | Development is our primary focus, although security audits, conference
> | attendance, and other community-based events can be included in the
> | application should they be necessary.

The thing is, we can ask STF relatively easily if theres a specific task
we want funded, to check what they think about it.
features are not the primary focus of STF but the way i understood is that
it would not be impossible for them to sponsor a feature if it fits their
mission

So STF seems quite reasonable.
If you have a specific project idea that you would want funded, i or thilo
can directly ask tara. I just dont want to ask hypothetical things. As that
could annoy STF.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

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.

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.

I also agree with Remi about keeping the money in Europe, FWIW.

And before it inevitably comes up, I am opposed to avradio / SDR work being submitted as
a project to STF. This is an official objection.

Cheers,
- The Peanut Gallery
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1865 bytes --]

Hi Derek

On Mon, Jan 29, 2024 at 02:38:42PM +0000, 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

>> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2757 bytes --]

Hi Derek

On Mon, Jan 29, 2024 at 06:37:44PM +0000, 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Vittorio Giovara]

On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer <michael@niedermayer.cc>
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

Le 29 janvier 2024 22:15:39 GMT+02:00, Derek Buitenhuis <derek.buitenhuis@gmail.com> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Vittorio Giovara]

On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov <anton@khirnov.net> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1611 bytes --]

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 <anton@khirnov.net> 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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 <anton@khirnov.net> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Diederick C. Niehorster]

On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara
<vittorio.giovara@gmail.com> wrote:
>
> On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer <michael@niedermayer.cc>
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

Quoting Diederick C. Niehorster (2024-01-29 21:41:29)
> On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara
> <vittorio.giovara@gmail.com> wrote:
> >
> > On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer <michael@niedermayer.cc>
> > 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <anton@khirnov.net> 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 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Stefano Sabatini]

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 things in
general, we would have some concrete project and candidate to get a
measure of what it could be like. I hope that if even we don't end up
with enough proposals, this should help to gain more experience to
understand what can and cannot work.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Stefano Sabatini]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 6551 bytes --]

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
>    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.

trivial ;)
we start with a wiki page
we add a some work with some monetary amount.
We wait.
If someone comes and is willing to do it for less, ok, if someone complains
its too much, not ok.
This seems the normal hire the "cheapest competent developer"


> 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.

yes, also please CC jonatan on questions related to teh SoW paperwork stuff
and SPI. He is not subscribed he can just post without subscribing because
of magic.
We can also ask STF for specific things but iam hesitant to CC given the
heat in this thread could reflect badly on FFmpeg.


> 
> 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.


[...]

thx
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 586 bytes --]

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.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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 need less time,
sometimes significantly less. Would STF be okay with us being so
wasteful?

> > 
> > 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.
> 
> trivial ;)
> we start with a wiki page
> we add a some work with some monetary amount.
> We wait.
> If someone comes and is willing to do it for less, ok, if someone complains
> its too much, not ok.
> This seems the normal hire the "cheapest competent developer"

This is not serious. "someone complains"? Like any random person? Any
developer? In a project like ours, someone will always complain. Does
that mean anyone has a veto over anything else?

Besides, 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.

-- 
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

> 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 <anton@khirnov.net> 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 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 need less time,
> sometimes significantly less. Would STF be okay with us being so
> wasteful?
>
> > >
> > > 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.
> >
> > trivial ;)
> > we start with a wiki page
> > we add a some work with some monetary amount.
> > We wait.
> > If someone comes and is willing to do it for less, ok, if someone
> complains
> > its too much, not ok.
> > This seems the normal hire the "cheapest competent developer"
>
> This is not serious. "someone complains"? Like any random person? Any
> developer? In a project like ours, someone will always complain. Does
> that mean anyone has a veto over anything else?
>
> Besides, 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.
>
> --
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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 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).

It's not so much fake hours as the problem of counting what time was
actually spent on this work - only a minority of time is spent typing
code.

> I hope this addresses some of your concerns.

Some of them, thank you.

-- 
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

> 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 <kierank@obe.tv> 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 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <jesusalva@spi-inc.org>
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. Nogueira (“jesusalva”)
> Board of Directors Member
> Software in the Public Interest, Inc.
>
>
> On Wed, Jan 31, 2024 at 12:17 PM Kieran Kunhya <kierank@obe.tv> 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 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

	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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

> 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”)
Board of Directors Member
Software in the Public Interest, Inc.


On Wed, Jan 31, 2024 at 1:11 PM Rémi Denis-Courmont <remi@remlab.net> wrote:

>         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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 634 bytes --]

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 +0000, 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@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?

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <kierank@obe.tv> wrote:

>
>
> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@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?
>
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Wed, 31 Jan 2024 at 18:40, Jonatas L. Nogueira <jesusalva@spi-inc.org>
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 <kierank@obe.tv> wrote:
>
>>
>>
>> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@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?
>>
>> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1056 bytes --]

On Wed, Jan 31, 2024 at 06:22:41PM +0000, Kieran Kunhya wrote:
> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@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 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Cosmin Stejerean via ffmpeg-devel]

> On Jan 31, 2024, at 11:07 AM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> 
> On Wed, Jan 31, 2024 at 06:22:41PM +0000, Kieran Kunhya wrote:
>> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@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




_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

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 <
> michael@niedermayer.cc> wrote:
> >
> > On Wed, Jan 31, 2024 at 06:22:41PM +0000, Kieran Kunhya wrote:
> >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <
> michael@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&selectedBooth=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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1638 bytes --]

On Wed, Jan 31, 2024 at 08:19:04PM +0000, 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Wed, Jan 31, 2024 at 08:19:04PM +0000, 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2180 bytes --]

On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:
> On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Wed, Jan 31, 2024 at 08:19:04PM +0000, 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:
> > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <
> michael@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Jan 31, 2024 at 08:19:04PM +0000, 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2990 bytes --]

On Wed, Jan 31, 2024 at 10:45:50PM +0000, Kieran Kunhya wrote:
> On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, <michael@niedermayer.cc>
> wrote:
> 
> > On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:
> > > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > On Wed, Jan 31, 2024 at 08:19:04PM +0000, 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


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

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 <michael@niedermayer.cc>
wrote:

> On Wed, Jan 31, 2024 at 10:45:50PM +0000, Kieran Kunhya wrote:
> > On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, <michael@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:
> > > > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <
> > > michael@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Wed, Jan 31, 2024 at 08:19:04PM +0000, 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-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <michael@niedermayer.cc>
wrote:

> On Wed, Jan 31, 2024 at 06:22:41PM +0000, Kieran Kunhya wrote:
> > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <
> michael@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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2590 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Stefano Sabatini]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Stefano Sabatini]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Jonatas L. Nogueira via ffmpeg-devel]

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 <stefasab@gmail.com> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1087 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Vittorio Giovara]

On Tue, Jan 30, 2024 at 2:48 AM Michael Niedermayer <michael@niedermayer.cc>
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Nicolas George]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Vittorio Giovara]

On Tue, Jan 30, 2024 at 11:07 AM Nicolas George <george@nsup.org> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Nicolas George]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Vittorio Giovara]

On Tue, Jan 30, 2024 at 11:15 AM Nicolas George <george@nsup.org> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1640 bytes --]

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 <michael@niedermayer.cc>
> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis@gmail.com>
wrote:

> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
>
> Not to derail this fine thread, but what forks does the Merge Forks
> project refer to?
>
> - Derek
>

I also added a note that 70 USD for coverity is way too much. I picked a
random issue 1503073 and within a minute saw that it was a false positive.
I don't deserve 70USD for that.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2873 bytes --]

On Wed, Jan 31, 2024 at 09:55:00PM +0000, Kieran Kunhya wrote:
> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis@gmail.com>
> wrote:
> 
> > On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> >
> > Not to derail this fine thread, but what forks does the Merge Forks
> > project refer to?
> >
> > - Derek
> >
> 
> I also added a note that 70 USD for coverity is way too much. I picked a
> random issue 1503073 and within a minute saw that it was a false positive.
> I don't deserve 70USD for that.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2274 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2781 bytes --]

On Wed, Jan 31, 2024 at 09:55:00PM +0000, Kieran Kunhya wrote:
> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis@gmail.com>
> wrote:
> 
> > On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> >
> > Not to derail this fine thread, but what forks does the Merge Forks
> > project refer to?
> >
> > - Derek
> >
> 
> I also added a note that 70 USD for coverity is way too much. I picked a
> random issue 1503073 and within a minute saw that it was a false positive.
> I don't deserve 70USD for that.

I fixed 2 coverity issues yesterday and it took me over 3 hours
I cant do this for 70USD per issue
(you can see the ML for the 2 patches)

In the first, the issue depended on fbw_channels to be 0.
If you look at its initialization that is possible if you have a
mono LFE channel but is that possible and can the code be reached
in that case.
For someone who hasnt worked at that specific code it takes some time
to build an argument that this should not be possible

The second issue, its obvious a bug but how do we even reach that code?
No fate tests ....
luckily there are examples in the docs but it took me several tries to
get the code to execute with similar testcases.
now looking at it, i suspect the patch i posted probably should be split
so we need a 2nd iteration
and looking at the clock when i posted this and when i started yesterday
fact is it was 3-4h work for these 2 issues

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Zhao Zhili]

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

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

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

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Derek Buitenhuis]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

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 <derek.buitenhuis@gmail.com> 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-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[J. Dekker]

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 
> <derek.buitenhuis@gmail.com> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Paul B Mahol]

On Sun, Feb 4, 2024 at 11:03 AM J. Dekker <jdek@itanimul.li> 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
> > <derek.buitenhuis@gmail.com> 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-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2868 bytes --]

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 
> > <derek.buitenhuis@gmail.com> 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

Hi,

Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer <michael@niedermayer.cc> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4069 bytes --]

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 <michael@niedermayer.cc> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Rémi Denis-Courmont]

Hi,

Le 4 février 2024 21:28:44 GMT+02:00, Michael Niedermayer <michael@niedermayer.cc> 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 <michael@niedermayer.cc> 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,

200000€ 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Sovereign Tech Fund

[Thilo Borgmann via ffmpeg-devel]

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-request@ffmpeg.org with subject "unsubscribe".