* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * THIS RELEASE STREAM IS OPEN TO BUG FIXES. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This file tracks the status of releases in the 1.7.x line. See http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization for details on how release lines and voting work, what kinds of bugs can delay a release, etc. Status of 1.7.0: Candidate changes: ================== * r1146131 and followups Add svn_fs_verify() and implement rep-cache verification in FSFS using it. Branch: 1.7.x-fs-verify Justification: Would be nice to extend verify already in 1.7.x. Notes: This does not include progress reporting, since that is nominated separately. Votes: +1: rhuijben +0: danielsh +0: gstein (progress would be nice) * fs-progress branch Notes: Depends on the r1146131 group (1.7.x-fs-verify). Branch: fs-progress Justification: Provide feedback during 'svnadmin verify'. Avoid an API change in 1.8. Notes: If this proposal passes, the docstrings @since would have to be fixed in a new commit. Votes: +0: danielsh * r1147540, r1147541 Remove unused variables in build system. Justification: Backporting of future changes will be easier. Votes: +1: arfrever * r1148083, r1148094 Preload libsvn_auth_gnome_keyring and libsvn_auth_kwallet in locally built executables. Justification: Version mismatch errors would occur during trying to use locally built executables when a different version of Subversion was installed in /usr/lib. Votes: +1: arfrever, philip * r1148992 Print error messages about failures of dynamic loading of libraries when SVN_DEBUG_DSO is defined instead of never. Justification: Suboptimal r1148374 was already backported in r1148488. Votes: +1: arfrever -0: rhuijben (A library shouldn't just write things to stderr. This needs proper error handling instead. And besides I doubt anyone is going to use this define (No veto!)) -0: philip (changed my mind, I don't think this is needed on the branch) -0: stsp (Arfrever, can you please explain precisely what use case you have for this code? Why do you need it in the release, or on trunk, for that matter?) * r1148043, r1151055 Allow building with serf trunk on windows. Votes: +0: danielsh (r1151055 only) +1: pburba, rhuijben -0: the serf 2.x API will be incompatible with 1.7.x, so this will never be useful * r1152189, r1152190 Fix an assertion on copying nodes that are not presence normal. Branch: 1.7.x-r1152189 Justification: Easy to trigger problem in tree conflict situations. Votes: +1: rhuijben +1: philip, gstein (the branch solves a merge conflict that arises when applying r1152190) * r1153138, r1153141 Don't CHECKOUT added directories when using a HTTPv1 server. Justification: Getting a HTTP 500 error while committing new directories is not nice. Notes: r1153141 removes an accidentally added SVN_DBG() from r1153138. Votes: +1: rhuijben, gstein Veto-blocked changes: ===================== * 1.7.x-neon-default branch Make neon the default http library. Justification: Serf's relative stability is inferior to that of the rest of Subversion, and for such a critical piece of our architecture, this is unacceptable. Subversion package producers have voiced a vote of no confidence, and plan to ship with Neon as the default: http://svn.haxx.se/dev/archive-2011-07/0751.shtml http://svn.haxx.se/dev/archive-2011-06/0796.shtml Bug reports of the crash variety continue to be reported: http://svn.haxx.se/dev/archive-2011-07/0735.shtml Serf floods the target server with orders of magniture more requests, resulting in undesirable server log bloat. Further, the promise of performance has not been realized: https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.csvn/wiki/HTTPv2 (As an aside, Serf's potential as a platform for future improvement remains unproven and doubtful. For example, HTTPv2 removes canonical resource URLs, which works against the caching proxy concept that seems to be the strongest argument in favor of Serf's approach. But that's not strictly germane here.) rhuijben: Trivial problems like r1153138 should have been fixed a long time ago if we don't want to delay releasing 1.7 on serf. markphip: I understand why *we* would want Serf as default, so we can make it better, but it goes against all of the other conservatism in this project to make this the default when we *know* it is less stable, potentially lacks some of the features and is generally considerably slower than Neon. Serf's use of chunked transfer encoding means that it isn't supported by some HTTP proxies. Votes: +1: philip, cmpilato, rhuijben, markphip -1: gstein (this backs away from previous discussions stating that serf is the desired future layer; the issue tracker has been free of 1.7.0 serf-related bugs for a while now) Approved changes: =================