On 06/11/2025 09:40, Nicolas George via ffmpeg-devel wrote:
Rémi Denis-Courmont (HE12025-11-04):
From a technical standpoint, that seems very agreeable indeed. But at
the same time, it sounds unreasonable to expect that of a bounty
claimant.
Can you elaborate why you think that? We set the rules.
AFAICT, the only way to resolve that contradiction is to not have
bounties for features that require design decisions at all. Otherwise
problems like the one you claim of the channel layout API are just
bound to repeat eventually.
That's not to say that they can't be sponsored some way, but not the
bounty way.
In fact, I tend to be against bounties in general. At least that
should not be the default model, IMO.
The channel layout API was not the result of a bounty, IIRC. AFAIK, we
do not know publicly how it was funded, or even if. We obviously have no
power to prevent somebody to work on a >100 patch series alone in their
free time, but unlike funded work there is no incentive to work alone.
I would agree with you to exclude things that require design from
bounties, but note that it would exclude the task discussed presently,
as “improve the filter negotiation around hardware filters” is mostly
design.
Couldn't we simply have any design-discussions and decisions before the
bounty is started, so the design becomes part of what the bounty is
posted for?
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
