[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