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.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
