On 8 June 2015 at 16:22, Branko Čibej <brane_at_wandisco.com> wrote:
> 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.
>
Done in r1684181.
>> 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.
>
I didn't think that any test suite failure should be called as release
blocker and after thinking more I agree that this particular failure
also should not be considered as blocker. Even it breaks my release
testing scripts, since failure in one configurations causes abort of
all test run :(
My original intention was "we need this fix in 1.9.x before 1.9.0 to
speed up release, because it could slowdown release signing process",
but I should put this in Note field instead marking nomination as a
release-blocker.
But I think that test failures could be release blocker in case it
happens in common configuration or affects many tests.
--
Ivan Zhakov
Received on 2015-06-08 15:38:23 CEST