[FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Sat, 27 Jan 2018 02:25:49 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Fri, Jan 26, 2018 at 12:52:19AM +0100, wm4 wrote:
> > On Fri, 26 Jan 2018 00:21:14 +0100
> > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >   
> > > 2018-01-26 0:00 GMT+01:00 Hendrik Leppkes <h.leppkes at gmail.com>:  
> > > > On Thu, Jan 25, 2018 at 11:35 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:    
> [...]
> 
> > 
> > I'd also like to point out that it _did_ happen in the past that
> > Michael went off tangents in patch reviews and asked for unreasonable
> > extra work because of minor issues.  
> 
> Ive written a huge number of reviews over the years, and i certainly
> did what you claim above in one of these many reviews. Not in the case
> you refer here to though. And if it happens, that a unreasonable request
> is made, discussion is whats needed. 
> In fact many developers have made requests that others have found
> unreasonable. Many if not most of the more active developers have.
> Its not a uncommon source of long discussions.

And so we're having a long discussion again. You could just have left
it alone.

> 
> 
> > The AVFrame.opaque_ref fiasco
> > (whose non-sensical later solution which he demanded was finally
> > pushed, even though it still does not solve the issues he claimed his
> > approach would solve) comes to mind,  
> 
> so much you say in here
> ill skip over "non-sensical" and "demanded" these are not really true in
> the way you present it here.

The "demanded" was definitely true. You blocked my patch, even though
it was just a Libav merge to begin with.

There were never big discussions about such tiny merges before, and
nobody would have given a shit had I pushed those merges directly to
git (like it's normally done with merges). But you started a big
discussion and eventually achieved that a sub-optimal solution was
added.

The current solution _is_ nonsense. There is now a semi-public field
(AVFrame.private_ref) in a libavutil struct that can be used only by
libavcodec, something which we always avoid, because the libraries are
supposed to use only the public API of each other (except avpriv_ and
headers).

It still doesn't solve the problem you claimed there was: if libavcodec
fails to "process" the private_ref contents, the returned frame to the
user will be broken and make the user application crash.

Oh, and of course the doxygen says AVFrame.private_ref can be used by
other ffmpeg libs too. So what happens if libavfilter's use of
private_ref clashes with libavcodec's? Please explain.

Absolutely NOTHING is helped by using a separate field instead of
opaque_ref, and you were the only one who insisted on doing this (the
others at best unaware of the details and vaguely trusting your claims).

You even ignored my solution, which was consistently checking all
entrypoints for opaque_ref (and wrapping the user use of it), which my
patches did. You didn't even care and somehow claimed there were holes
in it, which there were not, and even if there were, YOUR CURRENT CODE
WOULD FAIL TOO.

At this point I seriously had enough of your shit and left the project
for a while.

> the solution choosen IIRC does indeed not achive everything. It was
> in fact a compromise that resulted from the discussion of many developers.
> IIRC a solution that would solve all teh listed issues was not liked by
> multiple people

Because apparently they still wanted it to be merged, so they just did
whatever you wanted, whether it made sense or not. I on the other hand
was seeking a solution that was technically closer to ideal. But it was
impossible to get through you.

> > and I considered his general
> > conduct on this issue harassment (not like I'd get an apology).  
> 
> If anything i said felt like harrasment, i appologize. That said
> a review or comment or objection to a patch is not harrasment and
> I will continue to review and when it is needed object to changes.
> 
> Maybe it is just my point of view here but you seem very sensitive
> to anything that is not an approval of your changes.
> While at the same time your replies are often aggressive or offensive.
> 
> Just as random examples, your single line objection here certainly came
> over in a passive aggressive tone:
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224488.html

That's not passive aggressive. You know certain devs (including me)
don't like excessive logging code for fuzzing fixes, and that was
extensively discussed in the past. But there you go again. (And sure, I
can be convinced that the logging is actually OK in this specific case,
but you preferred doing something else instead.)

However, your reply was passive aggressive to the max:

> 
> and your next reply, that basically told me farewell when i said that i
> wouldnt continue to maintain or help maintain hevc when error messages
> would have to be ommited (not one specific one but in general)
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224506.html

You basically threatened that you'd stop doing important work on hevc
if you didn't get to add your error messages. Well, I ignored the
threat and just told you to do draw your consequences out of the
non-approval, if you really want to. I expect it was an empty threat
anyway.

Such "threats" are completely inappropriate in patch reviews.

You realize the irony of threatening something like this, while your
patch "reviews" made me leave the project for a while, right?

> And that was just a day or 2 ago. 
> 
> The very mail here i reply to is then also accusing me of harrasment 
> in patch review from last year. I dont exactly enjoy having to reply
> to these kind of accusations. More so considering how long ago the
> review is that refers to.
> 
> and on IRC 2 days ago
> 
> Jän 25 23:47:53 <jamrial>       <+wm4> also michaelni harassed me a lot in the past (like making me go through all that pointless crap when getting rid of the side data merging
> Jän 25 23:48:02 <jamrial>       can you drop that already? it was not pointless
> Jän 25 23:48:22 <jamrial>       i was careless and did a merge wrong, and google came out of the woodworks because i broke chromium
> Jän 25 23:48:41 <jamrial>       the abi concerns had a reason

Definitely the side data merging ABI claim was completely pointless. If
any application had a dependency on side data being merged, they would
have broken on the ABI bump. I don't know what jamrial is referring to.
Besides, packet contents were not considered ABI relevant before. My
own project was once broken by a packet format change - so what? I just
fixed it on my side.

Sure, these technical points can be fuzzy and I might be wrong too.
But it's not just about that. You fought pretty hard against my patches
and invented all sorts of arguments. You accused me of trolling too. I
didn't enjoy this interaction.

How come you find my claims illegitimate, but if I tell you something
as simple to drop the logging it's suddenly passive aggressive
harassment. Come on?

> I would really like to see these accusations stop, this is not something
> anyone else that i remember has done in FFmpeg or Libav, not at this scale
> at least.

Well, you remember how half of the project forked off years ago because
they were tired of your antics as project leader, right? That was pretty
big scale wasn't it? I'm not threatening to fork ffmpeg as a project or
anything close to it, nor do I want to unearth the Libav drama, but
your claim is certainly a bit of an exaggeration.

Anyway, I too would like if the harassment against me by you and CE
would stop. On a related note, I know no other project that would
tolerate CE's behavior at all.