[pulseaudio-discuss] [PATCH] Fix test-suite failure on Alpha

[David Henningsson]

On 2015-09-15 13:22, Arun Raghavan wrote:
> On 15 September 2015 at 16:46, David Henningsson
> <david.henningsson at canonical.com> wrote:
>>
>> On 2015-09-15 06:45, Arun Raghavan wrote:
>>>
>>> On 9 September 2015 at 15:19, Michael Cree <mcree at orcon.net.nz> wrote:
>>>>
>>>> Pulseaudio fails to build on the Alpha architecture due to a failure
>>>> in the volume-test of the test suite.  I had reported this to the
>>>> Debian bug tracker [1] but the maintainer has asked that I forward the
>>>> patch to this mail list.  The failure in volume-test occurs because it
>>>> is compiled with -ffast-math which implies -ffinite-math-only of which
>>>> the gcc manual states that it optimizes for floating-point arithmetic
>>>> with the assumption that arguments and results are not NaNs or
>>>> +/-infinity, and futher notes that it may result in incorrect output.
>>>> On the Alpha platform that is somewhat an understatement as the use of
>>>> non-finite floating-point arithmetic with -ffinite-math-only results in
>>>> a floating-point exception and the termination of the program.
>>>>
>>>> The volume-test converts volumes into decibels (so a zero volume
>>>> becomes a negative infinity) and proceeds to add two volumes (in
>>>> decibels), thus does arithmetic with non-finite floating point numbers
>>>> despite being compiled with -ffast-math!
>>>>
>>>> I attach a patch that protects against the arithmetic with non-finite
>>>> numbers for your consideration.  With that patch the test-suite passes
>>>> on Alpha.
>>>>
>>>> Cheers
>>>> Michael.
>>>>
>>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248
>>>
>>>
>>> Thanks for the fix! I've pushed this out to our next branch (since
>>> we're frozen for the 7.0 release, it'll only make it out in 8.0).
>>
>>
>> Hi Arun,
>>
>> Thanks for picking it up, but I think this is a typical example of a bug fix
>> that should go in 7.0 even though we're frozen. Not merging it only leads to
>> more buggy 7.0 release, and more distro patching for downstreams.
>
> Since this patch is for a test, and is rather trivial, I don't
> particularly mind either way.

Ok, I've now pushed it to master too.

> In general, though, I view each extra patch as a risk of regression
> when we are frozen, and as they add up, you start to need to do
> another RC, delaying the release. This is why I advocate a stricter
> (and thus, imo shorter) freeze period.

Every bug-fix patch is also a chance to get a less buggy release. It's 
all about the trade-off. For simple fixes like this one, the regression 
risk is low and the chance to get a less buggy release high.
A stricter freeze period would prohibit us from making that judgement on 
a patch-by-patch basis.

In general, I believe having a good quality release is more important 
than having a timely release (but that is also a trade-off - we'll never 
get to a 100% bug free program). Because if we let something buggy out, 
then I'll just have to distro patch it instead, and so must other 
distros, which means more work in total.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic