On 08.06.2015 14:53, Ivan Zhakov wrote:
> On 8 June 2015 at 14:37, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 08.06.2015 13:33, ivan_at_apache.org wrote:
>>> Author: ivan
>>> Date: Mon Jun 8 11:33:42 2015
>>> New Revision: 1684161
>>>
>>> URL: http://svn.apache.org/r1684161
>>> Log:
>>> * STATUS: Nominate r1684034 as release blocker.
>>
>> Ivan, a minor bug in the test suite isn't a release blocker by any
>> stretch of imagination. Please move the nomination to the "Other
>> candidates" list.
>>
> Hi Brane,
>
> Bert have already put his +1 and this is test-only, so two votes is enough.
>
> May be I just move this nomination to approved section
Go ahead, as far as I'm concerned.
> and we do not
> spend time arguing whether it's fine or not to release with test
> failures?
You're dodging the issue. It's not about releasing with test failures
but whether or not a test suite bug is a release blocker. There's an
enormous difference and yes, we do have to discuss this because
unreasonable assumptions about what is a release blocker are potentially
damaging.
We've made many releases with test suite bugs; essentially all of 1.8.x,
where the C tests don't work when configured with --enable-optimize.
Would it make sense to fix that? Maybe ... but it would cause a lot of
code churn for little benefit. Should this block any 1.8.x release?
Obviously not.
I'll even propose that a backport that doesn't require three +1 votes
can't, by definition, be a release blocker because it doesn't affect our
core functionality. Even more so if it only affects some
platforms/configurations.
For example, I recently posted my +1 vote for 1.9.0-rc2 on Windows 10
with MSVC14, even though JavaHL doesn't even build on that combination,
and that's a far "worse" result than your locale issue. But blocking a
release because of a known issue with an unreleased compiler would be
silly.
-- Brane
Received on 2015-06-08 15:23:30 CEST