Aug 14, 2019, 19:29 by mich...@niedermayer.cc: > On Tue, Aug 13, 2019 at 12:11:30PM +0200, Lynne wrote: > >> Aug 12, 2019, 20:53 by mich...@niedermayer.cc: >> >> > On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote: >> > >> >> On 08.08.2019, at 10:36, Michael Niedermayer <mich...@niedermayer.cc> >> >> wrote: >> >> >> >> > This provides an alternative to retry counters. >> >> > Useful if there is no reasonable maximum number of iterations and >> >> > no ordering that naturally avoids loops. >> >> >> >> Going by the old principle of "an API is not tested until it has at least >> >> 3 users" >> >> might it make sense to delay this until we've found and tested it in a >> >> few use-cases? >> >> Depending on how much hurry there is to get the bug-fix in. >> >> >> >> I assume there is also an actual bug-fix patch somewhere, maybe we should >> >> have that >> >> in the same patch series to make it easier to review the actual usage? >> >> >> > >> > sure will repost this eventually with 3+ bugfixes. >> > But wont search for such bugs ATM as ive too many other things to do >> > so it might take a bit of time before i do >> > >> > >> >> >> >> > diff --git a/doc/APIchanges b/doc/APIchanges >> >> > index 6603a8229e..eee4c30ec5 100644 >> >> > --- a/doc/APIchanges >> >> > +++ b/doc/APIchanges >> >> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 >> >> > >> >> > API changes, most recent first: >> >> > >> >> > +2019-XX-XX - XXXXXXXXXX - lavu 56.XX.XXX - loop_detector.h >> >> > + Add loop_detector.h, av_is_loop(), AVSimpleLoopDetector >> >> >> >> Does is mean it is a public/installed header? >> >> >> > >> > that was intended, but it can of course be trivially be kept local if >> > people >> > prefer when i repost with 3+ dependant fixes >> > >> >> You are ignoring 2 developers, and this isn't the first time you're doing >> this, nor even the second. >> I still do no think even with 3 bugfixes this deserves to be in lavu but >> rather in every library as a non-installed header, at the very most. I still >> prefer for code to be duplicated for such a small amount of fixes. >> Iit could encourage other developers to put this in their code when it isn't >> needed when a properly written loop would never go infinite. >> And, regardless where this code goes, its still as its been pointed out, a >> hack. >> > > why are you agressive ? >
I can't find a single hint of aggression in my email. I'm being direct and factual. If you see this as aggression you shouldn't read any specifications or reports, you'll find yourself very offended. > this is just a patch that is not ready to be applied as reimar asked for 3 > dependant bugfixes. > We can discuss where to put the header when theres actual code that can be > commited. discussing it before we can see the whole patchset makes no real > sense. > I mean you complain that something would have been done thats not even > possible ATM given the peoples requests in the review ... > I couldn't help but perceive the discussion you were having and your intentions to post another version as ignoring others' opinions. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
