[FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

James Almer jamrial at gmail.com
Sun Jan 13 18:14:50 EET 2019


On 1/13/2019 12:57 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> And kill the project by reducing development speed to crawl? Unreviewed
> 
> That is indeed the problem.
> 
>> and unchallenged patches by long time devs with commit rights can and
>> will still be pushed after enough time and ping attempts have been made.
>> Expecting anything else will take ffmpeg through the same road libav
>> found itself in.
>> Bad commits that were ignored but noticed after the fact have been
>> reverted in the past. They will inevitably crash under the weight of its
>> own crappiness. That will not change.
>>
>> Rewrite this patch, make it palatable, and then the rest of the project
>> will consider it. Stop wasting your and everyone's time by insisting on
>> a patch everyone NAKed.
> 
> You keep saying that, but you waltz around the problem. So let me state
> it plainly:
> 
> If there is somebody (1) who repeatedly pushes patches without review
> (because it is new code or because it is over code that they maintain by
> self-appointment), (2) whose patches frequently cause regressions, some
> of them detected by Coverity, (3) when they get a review and it requires
> more work from them, are rude and unhelpful, and possibly ignore the
> comments, (4) as a result from that rudeness receive even less reviews,
> and (5) all this seems to be motivated by sponsorship, can you tell what
> course of action you propose?

(1) is not an issue, (2) and (3) are the issue, and depending on the
developer's reaction at reviews and request for fixes, it should result
in the removal of commit rights.
Have you seen something forcefully pushed after reviews or concerns were
ignored by the committer because they capriciously didn't like said
reviews or reviewer, that wasn't eventually reverted or adapted? Does
the recent patch by Paul that prompted this abomination of a patch fit
the above criteria?

And (5) is completely irrelevant for the above. Bad code is bad code,
and bad behavior is bad behavior, regardless of the incentive behind it.
This patch of yours pretends to magically fix (2) to (4) by assuming
tackling (5) will have any effect.


More information about the ffmpeg-devel mailing list