On 8 June 2015 at 16:22, Branko Čibej <br...@wandisco.com> wrote: > On 08.06.2015 14:53, Ivan Zhakov wrote: >> On 8 June 2015 at 14:37, Branko Čibej <br...@wandisco.com> wrote: >>> On 08.06.2015 13:33, i...@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
