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. > 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
