[FFmpeg-devel] STF SoWs

[Paul B Mahol]

On Tue, Feb 6, 2024 at 7:17 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

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

If this is again about SDR, go ahead,  merge it. I no longer care.


>
> 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"
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>