[ogg-dev] [Bulk] Re: Make check failure

Gregory Maxwell gmaxwell at gmail.com
Mon Apr 5 07:39:25 PDT 2010


On Mon, Apr 5, 2010 at 10:15 AM, Neil Leathers <neil.leathers at rogers.com> wrote:
>> If the new function stays it will likely need a test case. I'm not
>> going to write one until the decision is final that we'll go that
>> route.
>
> ... without testing the change (to demonstrate it works, or is useful, or ... anything) ...

Of course I tested the change. Moreover, the change isn't of a nature
which could cause failure beyond the minimum extent _any_ change can
be expected to cause failure.

> ... with misleading check in comments.

Come on now.

> ... the test suite isn't particularly useful and ...

It is useful for its intended purpose:  It checks the that libogg
behaves exactly the way the check expected to behave.  For example, it
hands libogg a sequence of packets and validates that the output is
exactly as expected, down to the checksums.  Any change in the default
pagination will cause test failures until the test is updated to
reflect the new behaviour.

> ... it is normal to break the test suite and patch it later.
>
> I know some places insist on updating the test suite with altered and new test when (or before) committing new functionality. For libogg, the approach is to commit to HEAD first and possibly test it later? When it comes to new functionality, rather than discussing it on the list, one commits the code first and discusses later if anyone comments? This definitely accelerates adding new changes.

No, I'd been discussing it on IRC, along with the justification and
such.  Checking the commit log, discussions on the IRC channels are
inclusive of every developer to commit to libogg since 2006 (2004,
save one person).


More information about the ogg-dev mailing list