You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2008/07/24 14:52:36 UTC

1.5.1 up for signing/testing

Coming to you live from OSCON 2008, I'm pleased to announce that Subversion 
1.5.1 is up for testing and signing.  The magic revision is r32289:

http://test.hyrumwright.org/svn/1.5.1/

(Please make sure you verify the checksums.  I think all the bits made it to the 
download site, but just want to be sure.)

You know the drill: signatures from full committers back to me, and enthusiastic 
tester feedback is welcome.  At this point, this candidate is not yet blessed 
for wide release, so please don't make it available to people not interested in 
test-driving the new release.  Even though the code has been tested and signed 
previously, please test and sign this release to ensure code completeness and 
that I didn't bork the packaging somehow.

Distro package maintainers, please do NOT include any pre-release builds, even 
blessed, into operating system distros.  The reasons for not doing so were very 
eloquently outlined by Karl in a mail, which is summarized at the above address.

The quick version is: we don't guarantee compatibility between the pre-releases 
and the final release, so if people install the release candidate, all their 
repositories and working copies might break unrepairably when they upgrade to 
1.5.1 proper.  We don't want that kind of bad publicity, and neither do you.

-Hyrum

Re: 1.5.1 up for signing/testing

Posted by Ivan Zhakov <ch...@gmail.com>.

On Thu, Jul 24, 2008 at 6:52 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Coming to you live from OSCON 2008, I'm pleased to announce that Subversion
> 1.5.1 is up for testing and signing.  The magic revision is r32289:
>
> http://test.hyrumwright.org/svn/1.5.1/
>
> (Please make sure you verify the checksums.  I think all the bits made it to
> the download site, but just want to be sure.)
>
I'm +1 for release.

TESTED: [ fsfs ] x [ file | svn | http (neon) ]

RESULTS: All passed.

PLATFORM:
Windows XP Pro Version SP3
MS Visual Studio 2005 SP1

DEPENDENCIES:
apr: 1.3.0
apr-iconv: 1.2.1
apr-util: 1.3.0
neon: 0.27.2
zlib: 1.2.3
OpenSSL: 0.9.8g
Apache: 2.2.9

SIGNATURES:
subversion-1.5.1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQBIl2oC9g0ZgMTzooERAg9JAJwNaPF/0oRLD4LGs09Zdkc2aKeHwwCfckm3
mBer2TASxn3OqD210W2LNPg=
=udRC
-----END PGP SIGNATURE-----

-- 
Ivan Zhakov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 1.5.1 up for signing/testing

Posted by Julian Foad <ju...@btopenworld.com>.

On Thu, 2008-07-24 at 07:52 -0700, Hyrum K. Wright wrote:
> Coming to you live from OSCON 2008, I'm pleased to announce that Subversion 
> 1.5.1 is up for testing and signing.  The magic revision is r32289:
> 
> http://test.hyrumwright.org/svn/1.5.1/
> 
> (Please make sure you verify the checksums.  I think all the bits made it to the 
> download site, but just want to be sure.)

Summary:

    +1 to release

Tested with "make check":

    [ bdb, fsfs ] x [ local, svn ]
    swig-pl, swig-py

    Verified that all 6 distribution packages match their md5sums,
sha1sums and "to-tigris" copies.

Results:

    All tests pass.

OS/Platform:

    SuSE Linux Enterprise Desktop 10 SP2 (i686, kernel 2.6.16)

    Using in-tree build of subversion-deps packages:
       neon

    Using SuSE distribution-supplied packages:
       apr      libapr1-1.2.2-13.2
       apr-util libapr-util1-1.2.2-13.2
       bdb      db-4.3.29-15.2
       openssl  openssl-0.9.8a-18.26
       perl     perl-5.8.8-14.7
       python   python-2.4.2-18.13
       zlib     zlib-1.2.3-15.2

Signatures

    ::: subversion-1.5.0.tar.bz2 :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBIia7ZNR8z5DU+JbwRAqeBAKCOfDycmoLvpplXbLRVrvFYAXppMgCffeXI
cvWkM4qPXqV7lYvQY4Wnhl8=
=+rL1
-----END PGP SIGNATURE-----

    ::: subversion-1.5.0.tar.gz :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBIibGLNR8z5DU+JbwRAl6dAJoDvz3z45EweH77/KbgUApW6iFqagCfbdcb
OlTj7XF75yHuF5F1syel5Q8=
=gK0P
-----END PGP SIGNATURE-----


- Julian



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 1.5.1 up for signing/testing

Posted by Lieven Govaerts <sv...@mobsol.be>.

Branko Čibej wrote:
> Lieven Govaerts wrote:
>> Branko Čibej wrote:
>>> Can someone please remind me why those two serf tests aren't XFAIL?
>> Why would we do that??
>>
>> Those two tests you are referring too are fixed, but now 10 other 
>> tests are failing. Those are fixed on trunk too and a backport branch 
>> is ready, but too late for being included in 1.5.1.
>>
>> If people are not interested in seeing the test results of ra_serf, 
>> why even bother running those tests while signing?
>
> I don't see the connection here? XFAIL was designed to flag tests that 
> are known to fail in certain configurations. It's valid to have XFAIL 
> on one branch but not on another.
I agree, but what do you hope to achieve with marking these 10 failing 
tests as XFail?

XFail is a way to silence test errors that we are not planning to solve 
in the near future. There are only two situations that I can think of 
for marking a test as XFail:
1. The test is marking the 'acceptance criteria' for a new feature in 
development. XFail here means: svn should behave like this but we didn't 
implement the necessary functionality yet. This could be module 
specific. Suppose we had a test for PKCS#11 support, than that should be 
marked as XFail over ra_serf as this feature was only implemented in 
ra_neon.
2. Someone reported an issue and a test is added to reproduce it and 
indicate expected behavior. XFail here means that the issue is known, 
but unfixed.

These failing tests do not fall into one these two categories, because 
all of the tested functionality used to work in trunk and 1.5.0, meaning 
we are introducing regressions in svn 1.5.1 over ra_serf.
Do you agree that we should never mark tests that fail because of 
regressions as XFail? Even if it's in an experimental module as ra_serf?

The only effect of marking these tests as XFail, is that we are hiding 
these regressions for our users and ourselves indefinitely. It's not 
that we review the list of XFailing tests every week or so.

Lieven

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 1.5.1 up for signing/testing

Posted by Branko Čibej <br...@xbc.nu>.

Lieven Govaerts wrote:
> Branko Čibej wrote:
>> C. Michael Pilato wrote:
>>> It was just brought to my attention that I *should* have seen serf 
>>> tests failing.
>>
>> Can someone please remind me why those two serf tests aren't XFAIL?
> Why would we do that??
>
> Those two tests you are referring too are fixed, but now 10 other 
> tests are failing. Those are fixed on trunk too and a backport branch 
> is ready, but too late for being included in 1.5.1.
>
> If people are not interested in seeing the test results of ra_serf, 
> why even bother running those tests while signing?

I don't see the connection here? XFAIL was designed to flag tests that 
are known to fail in certain configurations. It's valid to have XFAIL on 
one branch but not on another.

I've since been reminded that in this case we can't reliably XFAIL the 
tests because we don't (yet) have the bits in the test infrastructure 
that would allow one to write the appropriate condition with consistent 
results.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org