[FFmpeg-devel] The "bad" Patch
softworkz .
softworkz at hotmail.com
Thu May 29 05:59:26 EEST 2025
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> softworkz .
> Sent: Mittwoch, 28. Mai 2025 17:25
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: [FFmpeg-devel] The "bad" Patch
[..]
That nobody has responded is not much surprising, but don't worry,
all actors will get covered.
Let's start with the origin and see how this story got poisoned in the first place
On IRC, 2025-05-15
21:25 <ramiro> oh, wow. are we really calling system(cmd)?
=> yes. it's done for reasons that I could explain if somebody would ask me
[..]
21:43 <jamrial> was this reviewed at all?
21:48 <BtbN> Not properly I guess, it is/was a huge patchset, and reviewing it is annoying with that Github-Forwarder
[..]
21:49 <BtbN> Why on earth does it even need to open a browser?
21:49 <BtbN> Just print the bloody url
21:52 <BtbN> And yeah, that commit message is super odd. On the ML I see a bunch of unresolved comments as well.
=> Hadn't looked properly. Later he named messages from revision 3 (but it was at v12 already)
[..]
21:53 <jamrial> someone was a bit too eager to push i guess
21:53 <jamrial> michaelni: maybe don't give push access to people so quickly...
[..]
22:16 <jkqxz> At least if you pass the sg option then it accidentally overwrites the user-supplied file name so it
can't be used directly for shell injection.
=> of course: when I do the right thing, it must be accidentally...
[..]
This is how mob-building works at a small-scale level.
Nobody might have had bad intentions in the first place.
But BtbN was already primed by his aversion towards the GitGitGadget submission I use,
and that gave a direction, the others followed.
It still doesn't mean bad intentions, they had good will in fact.
But they had lost respect towards me at large - which had consequences.
This can be seen in their subsequent behavior:
James Almer (jamrial)
=====================
Mailing List
"Absolutely not, wtf. Calling an external application like this?
Revert this patch or remove this effect immediately."
[He didn't even take the effort to put the comment at a place that corresponds to "like this?"]
"And there are still unresolved comments you didn't take into account
before pushing this set."
[I responded that's not the case]
"No, there's no need to involve the TC when everyone is telling you that
something is wrong. You pushed this set before even addressing all reviews."
[Repeated the same false claim, despite my response]
=> My questions to James
- Do you think it was right to spread out that false information without
validating yourself?
I mean publicly - where many will be reading it and it will stick in their
memory - possible for a long time.
- Do you think your reaction was adequate, not even really looking at the
patch like a developer and going crazy on the ML instead?
Especially, when considering that nobody had objected in the same way when
it would have had the equivalent code of system() in the patch?
- How would you have behaved when the patch would have been from somebody else
(e.g. Andreas)?
Ramiro
======
He didn't let himself turn that much in the direction of the others.
He tried to be friendly and mediate. Just the ChatGPT texts were a bit odd.
=> Only one question to Ramiro
- How do you see the situation now, that you know that nobody would
have objected (like this) when it would have had the inlined
implementation of system()?
Timo Rothenpieler (BtbN)
========================
When I make a mistake or do unjust to anybody, then I apologize clearly and
sincerely.
But I also don't like demanding for apologies. Demanded apologies are more
a matter of humiliating someone and that's not my interest. Only sincere
apologies have a value in my eyes.
I hope he realizes at least how the false information that he had spread
had caused the situation to turn into a really bad direction.
=> Questions to Timo
- You have been the first and foremost strongest opponent of using the system
API, even when others said that it's no longer a red flag when it's not done
in lib code; you named things for why it's bad and must be reverted.
Now that we see the full picture of the code, please explain your position:
Is it still a "no-go" or not?
If yes, could you please explain to me in detail what exactly is
bad about using that API in THIS WAY and in THIS CONTEXT?
Which bad things can happen and how exactly?
Mark Thompson
=============
He's an exception. I think he is probably only one who has really looked at the
code. He had made the single - and by far - most valid point at that time.
(about the temp directory determination).
He was friendly, respectful and professional.
Thanks Mark, much appreciated!
(I have no questions)
Best regards
sw
More information about the ffmpeg-devel
mailing list