[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1684161 - /subversion/branches/1.9.x/STATUS

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 8 Jun 2015 16:37:53 +0300

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

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

This is an archived mail posted to the Subversion Dev mailing list.