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

[Neil Leathers]

So if I understand the libogg development practises correctly.

>> (r17098 | gmaxwell | 2010-03-29 16:35:11 +1100 (Mon, 29 Mar 2010))

Gregory Maxwell checked in a change ...

>> I've just grabbed a copy of SVN head for libogg and 'make check'
>> is failing:

... which broke the test suite ...

> 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) ...

> As far as controversial goes, I probably should have put it in scare
> quotes. The kind of controversial I'm talking about is the name of the
> function I added (I don't like _fill() much myself, but nothing better
> seemed obvious)  or the decision to add a somewhat kludgey additional
> input function rather than break the ABI and add a one shot control.

... with misleading check in comments.

However it is rather moot since ...

> Nothing is broken.  The libogg test-cases are especially particular
> checks on exact (non-normative) aspects of the library behaviour. This
> is fine for their intended use: catching compiler/porting bugs on
> target systems, but it makes them less useful for development
> regression testing.

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

> In this case, I didn't update the test case while making the change.
> 
> Xiphmont left the tree in exactly the same state after making the
> change to pack 4 frames, this was fixed in r17039.  As far as where
> changes are made— we have _releases_ for the purpose of providing
> stable code, though because the norm around here is to have a mostly
> working trunk I never would have committed a change which could
> reasonably have been expect to cause any real breakage.

... 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.

Neil Leathers