On 1/13/2019 1:29 PM, Nicolas George wrote: > James Almer (12019-01-13): >> (1) is not an issue, > > It is an issue because it makes the rest possible. After all, people > whose main motivation is code quality would want their code reviewed. > >> (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. > > I was not ready to go that way, but since you put that on the tale, be > aware that I will hold you to it.
And what was your idea, if not that? You complain about people potentially forcefully pushing patches after ignoring NAKs or request for fixes. If the person can't be convinced to stop doing that, what else can you do to stop them? A temporal ban for first time offenders and such could maybe work. But then we're back to the CoC discussion that went nowhere. > >> Does >> the recent patch by Paul that prompted this abomination of a patch fit >> the above criteria? > > If they happened in the future and not in the past (decisions should not > be retroactive), I would consider this: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237979.html > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238166.html > > (I notice that you did call him out on the second, and I appreciate it) > to count as strikes one and two. > >> 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. > > I am not very surprised to see technical types ignoring sociological > evidence, but it is saddening. And again, you think requesting the disclosure of the incentive behind the patch will make a difference on the behavior of a person questioned for ignoring reviews? On top of being unacceptable in its current form, this patch is evidently misguided. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel