| Message ID | 20170703011811.GR4727@nb4 |
|---|---|
| State | Not Applicable |
| Headers | show |
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).
- Derek
On Mon, 3 Jul 2017 16:17:42 +0100 Derek Buitenhuis <derek.buitenhuis@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. So stop this.
On Mon, Jul 3, 2017 at 5:39 PM, wm4 <nfxjfg@googlemail.com> wrote: > On Mon, 3 Jul 2017 16:17:42 +0100 > Derek Buitenhuis <derek.buitenhuis@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. - Hendrik
On Mon, 3 Jul 2017, Hendrik Leppkes wrote: > On Mon, Jul 3, 2017 at 5:39 PM, wm4 <nfxjfg@googlemail.com> wrote: >> On Mon, 3 Jul 2017 16:17:42 +0100 >> Derek Buitenhuis <derek.buitenhuis@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
On 7/3/17, Marton Balint <cus@passwd.hu> wrote: > > > On Mon, 3 Jul 2017, Hendrik Leppkes wrote: > >> On Mon, Jul 3, 2017 at 5:39 PM, wm4 <nfxjfg@googlemail.com> wrote: >>> On Mon, 3 Jul 2017 16:17:42 +0100 >>> Derek Buitenhuis <derek.buitenhuis@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?
Le quintidi 15 messidor, an CCXXV, Paul B Mahol a écrit :
> What would then remain for Carl and folks?
Do you show such despise for other people's work on purpose or is it
your real opinion seeping through?
Regards,
On 7/3/2017 12:45 PM, Hendrik Leppkes wrote: > On Mon, Jul 3, 2017 at 5:39 PM, wm4 <nfxjfg@googlemail.com> wrote: >> On Mon, 3 Jul 2017 16:17:42 +0100 >> Derek Buitenhuis <derek.buitenhuis@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. The test can be renamed. What can't be changed in the sample name if it's already used in a release.
On 03.07.2017, at 17:17, Derek Buitenhuis <derek.buitenhuis@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). Sure, it would be nice if they had nice names etc., but it's a regression test, it caught a real issue, and it certainly costs on average less time to debug even these opaque test than debugging and fixing after a user finds it... Or maybe I've just been working for too long with randomly generated tests that you simply have to accept and debug as not making any sense...
--- ./tests/ref/fate/copy-trac3074 2017-07-02 00:09:52.091619495 +0200 +++ tests/data/fate/copy-trac3074 2017-07-03 03:16:18.208151309 +0200 @@ -1,4 +1,4 @@ -39aef1afff761d673fd1be07182941d1 *tests/data/fate/copy-trac3074.mp4 +364bdfb3ed40bf4a3517f978f6b7b9e3 *tests/data/fate/copy-trac3074.mp4 333991 tests/data/fate/copy-trac3074.mp4 #tb 0: 1/48000 #media_type 0: audio