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. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
