[FFmpeg-devel] STF SoWs

[Ronald S. Bultje]

Hi,

On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas <ffmpeg at haasn.xyz> wrote:

> On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <rsbultje at gmail.com>
> wrote:
> > Hi,
> >
> > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <
> michael at 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 at 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.

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.

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.

Ronald