On 7/3/17, Marton Balint <c...@passwd.hu> wrote: > > > On Mon, 3 Jul 2017, Hendrik Leppkes wrote: > >> On Mon, Jul 3, 2017 at 5:39 PM, wm4 <nfx...@googlemail.com> wrote: >>> On Mon, 3 Jul 2017 16:17:42 +0100 >>> Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: >>> >>>> On 7/3/2017 2:18 AM, Michael Niedermayer wrote: >>>> > breaks fate >>>> >>>> I'll look into it tonight; busy today. >>>> >>>> . >>>> . >>>> . >>>> >>>> Aside: >>>> >>>> I'll just add, though, that these two word 'breaks fate' emails >>>> are kind of obnoxious when the test in question was added days >>>> after I sent the set, so I couldn't have possibly tested against >>>> it, and the commit that added the test and this email has /zero/ >>>> info about what the test actually tests (a bug id is not a commit >>>> message). >>> >>> This. These opaque fate tests are so much work to get around. It went >>> far enough that I added bullshit to ffmpeg.c to get around some of the >>> questionable tests. >>> >>> Also, TRAC issue numbers have 0 information contents. Even if you go >>> through the obnoxious process of looking it up on TRAC and trying to >>> extract iunformation from a confusing discussion with a confused user >>> (99% of TRAC issues), TRAC could easily go away. It already happened >>> once, and some of the bug numbers in old commits obviously don't match >>> with what's on current TRAC. >>> >> >> I agree, this test could've easily been named something useful, like >> fate-mp4-copy-eac3 or whatever namespaces we use for mp4 tests, which >> would convey the same information without having to lookup the ticket >> on trac. >> > > Can't the project pay someone to make fate tests from fixed trac tickets? > Or make this an outreachy goal, like API tests, or something like that.
What would then remain for Carl and folks? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
