You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2015/06/08 13:37:12 UTC
Re: svn commit: r1684161 - /subversion/branches/1.9.x/STATUS
On 08.06.2015 13:33, ivan@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.
-- Brane.
Re: svn commit: r1684161 - /subversion/branches/1.9.x/STATUS
Posted by Branko Čibej <br...@wandisco.com>.
On 08.06.2015 15:37, Ivan Zhakov wrote:
> 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 :(
Yeah, that's painful ... of course, you can always fix your scripts. :)
> 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.
Ack.
> But I think that test failures could be release blocker in case it
> happens in common configuration or affects many tests.
Ack, makes sense.
-- Brane
Re: svn commit: r1684161 - /subversion/branches/1.9.x/STATUS
Posted by Ivan Zhakov <iv...@visualsvn.com>.
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, ivan@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
Re: svn commit: r1684161 - /subversion/branches/1.9.x/STATUS
Posted by Branko Čibej <br...@wandisco.com>.
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, ivan@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
Re: svn commit: r1684161 - /subversion/branches/1.9.x/STATUS
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 8 June 2015 at 14:37, Branko Čibej <br...@wandisco.com> wrote:
> On 08.06.2015 13:33, ivan@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 and we do not
spend time arguing whether it's fine or not to release with test
failures?
--
Ivan Zhakov