[FFmpeg-devel] Donations and what happens with them

[Jason Garrett-Glaser]

On Sat, Jan 29, 2011 at 3:23 AM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Jan 29, 2011 at 12:13:44PM +0100, Stefano Sabatini wrote:
>> I see that the current system (committer vs. developer) is adopted for
>> forcing the review process with no exceptions and thus avoiding
>> post-commit flames due to not-reviewed controversial changes, I wonder
>> if it would be a good idea to simply impose the same restrictions via
>> policy rather than via the commit mechanism itself.
>
> And I still don't see this working. Again and again I see a patch
> getting complains because it isn't the perfect solution, despite the
> fact that it fixes a crash or even a showstopper bug, then you try to discuss
> it but the "reviewer" is not motivated enough to give more than one
> reply a week even if you ping and two years later you still have the
> same crash/whatever.
> Unless you have some magical formula to change that behaviour I consider
> the possibility to say "if you don't do something about it, I will commit"
> a _necessity_ to a functioning development.

But I saw this as just as much of a problem before the change, too.
Very often, you would have some problem X and some patch Y that fixes
it.  Patch Y isn't perfect, and doesn't solve the problem in the best
possible way.  Reviewers suggest or insist that patch Y do complex,
harder thing Z to solve the problem better.

It never happens, and problem X remains.

A good example is the 6ch->2ch resampling bug, which has been around
for 2-3+ years now and is really, really embarrassing, especially
considering the first google result has a link to a patch that applies
cleanly to git trunk.

Jason