Re: [FFmpeg-devel] STF SoWs

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi

On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas <ffmpeg@haasn.xyz> wrote:
> 
> > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <rsbultje@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > > > michael@niedermayer.cc>
> > > > > wrote:
> > > > >
> > > > > >       2. Deliverables
> > > > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > > > >
> > > > >
> > > > > I think the goal is to get patches merged, not submitted.
> > > >
> > > > Yes but the individual developer cannot gurantee that.
> > > >
> > >
> > > In a bad situation, someone could send unmergeable patches and they will
> > > satisfy the legal requirement above for being paid out. I'm suggesting to
> > > protect the project against that situation.
> >
> > Unless I misunderstood you, what you are proposing protects the
> > Sovereign Tech Fund (aka German government), not the FFmpeg project.
> > This would only be a concern if we were funding work directly from the
> > (non-existant) FFmpeg treasury.
> >
> 
> It was more about project reputation and the goals being pro-project rather
> than pro-developer. Look at it this way: if patches get submitted but not
> merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's
> reputation to secure the funding. Subsequent funding rounds will be more
> difficult.

> Requiring a merge protects the project against this bad
> situation.

"Requiring a merge" does not do that
because lets assume we have a SoW that says "merge to git master" is needed
now this merge is blocked by someone successfully
That means the SoW is not fullfilled, the developer is not payed and STF
has paid SPI. That would ruin FFmpegs reputation even more as
STF is unhappy (they paid and didnt get what was written in the SoW)
the developer was not paid, so she would definitly be unhappy
SPI as the one in the middle would also be in a very uncomfortable
position.

So i think we should make sure the conditions in the SoW are guranteed to be
achievable


> 
> I understand that, hypothetically, if STF had funded SDR, this would be
> problematic, because no payment is possible for work a majority of the
> project's constituents doesn't want in. But maybe that ensures project
> funding is requested for conservative sets of tasks that everyone agrees
> are good for FFmpeg. So I don't see it as all bad. I don't think anyone is
> realistically planning to find a GA or TC majority to block patches that
> fix problems found by a static analyzer from going in, purely because it is
> known that work was paid for? That doesn't sound realistic to me. We've
> historically approved such patches without knowing it being declared
> whether they were paid for or not.

We have had multiple fixes blocked from going in.
There was the "i have a file this breaks, i will not share the file" cases
There where timeout fixes blocked because someone did not like some check
There was even general argumentation about OOM/Timeout fixes to be better
not done and rather running ffmpeg in a VM (which does not solve the problem
that the timeouts slow the fuzzer down)
Some fixes involving checking file extensions and similar also where not
popular
There was a time some people tried to block bugfixes if they printed an error
message. (thats why now none of my fixes prints an error message unless similar
cases do already)
I even remember that a paid bugfix in a demuxer (mov?) was rejected, the customer
was perfectly ok with that and paid me. I think i pointed it out to him
prior like i do with everyone nowadays that merge to git master cannot be
guranteed.
This is just what i remember at the spot.

Assuming the TC will solve it is brave because the TC is new and predates
most of the examples above.

I disencourage people from putting "merge into git master" as a
deliverable. It can get you burned in FFmpeg.


>
> But look at it from a higher level: you guys are asking for review of the
> STF task proposals, and I'm trying to find problems where they exist. I
> don't think the problem I find - or solution I propose (s/submit/merge/) -
> is crazy. I'm OK with different "fixes" for this problem I'm pointing out.
> But saying that it's not a problem... I disagree with that.

if "merge to git master" is a requirement then iam not participating
in this. The risk simply outweights the gain. I wont work for months to
then be at the mercy of not a single of 2000 subscribers posting some
"i object" and all 2000 know in this situation it would cause an
inconvenience to me.

I also recommand everyone else not to put their signature under a
SoW that lists things they cannot gurantee to achieve. I have once lost a large
customer from not considering adequately the FFmpeg communities ability to block
things. So its not even a hypothetical problem (no, noone knew it was paid work
it was not intentional)

thx

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"

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

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

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

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