blob: 08880773736f7a9dd221ce6853f19097fd86bb6e [file] [log] [blame]
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* THIS RELEASE STREAM IS OPEN TO BUG FIXES. *
* *
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
This file tracks the status of releases in the 1.8.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.8.14:
Candidate changes:
==================
* r1536854
Make 'svnadmin verify' detect inconsistencies that will prevent loading
dump files.
Justification:
Some users rely on dump files as a means of repository backup. Without
this patch, there is no way except of 'svnadmin load' to know that these
dump files will load at all. With this patch, a successful verify run
should guarantee loadable dump files.
Branch:
^/subversion/branches/1.8.x-r1536854
Votes:
+1: stefan2, breser
-0: julianfoad (test is missing from branch -- how do we know it works?)
* r1654932, r1654933, r1654934, r1654937
Fix issue #4554, "0 file length reported in FSFS".
Justification:
This causes 'svnadmin dump' to create corrupted output that fails to
load and we provide no way to detect that problem other than loading
the respective dump. We also want to prevent further instances of
that issue to be added to the repository.
Notes:
r1561419 has been removed from this change set and proposed for a
separate backport because it is not a necessary part of the #4554 fix.
Branch:
^/subversion/branches/1.8.x-issue4554-v2
Votes:
+1: rhuijben, stefan2
+0: danielsh (hard to review all potential causes of expanded_size==0 in
7*3*2 cases (1.11.8) × (file/dir/prop rep) × (plain/delta))
* r1666965, r1667120
Reduce 'the lag' of the first svn log results over mod_dav.
Justification:
A slow svn log makes users call Subversion slow. This fixes the
perceived performance problem by no longer optimizing just for
obtaining all the results fast, but also for obtaining the first
result fast.
.
Just the perceived slowness of common svn log operations might
make users switch to a DVCS or implement a client side cache,
while this slowness is just a buffering to make the total set of
results come in faster. But I don't think there are that many users
that really wait for all results of
.
$ svn log -q ^/subversion/trunk
.
This currently takes > 10 seconds before the first result using
the EU mirror for me. With --limit 1 (best comparison with post-patch)
that would be 0.2 seconds.
Votes:
+1: rhuijben, philip (After it has been approved for 1.9)
-0.5: ivan (It's not security or bug fix. The change itself a little
bit controversial for me, so it's better to release it as
part of Subversion 1.9.0)
* r1669955
Reduce FSFS memory allocation in Apache with unbounded MaxFreeMem.
Justification:
A user reported that their worker processes ran OOM with Apache 2.2
in default configuration when fulltext caching was enabled. Although
people should set MaxFreeMem to something other than 0, we should
play nice with out-of-the-box setups.
The patch itself is relatively low-risk (changes initial buffer size).
Branch:
^/subversion/branches/1.8.x-memory-fragmentation
Votes:
+1: stefan2, brane
* r1687812
mod_dav_svn: Use LimitXMLRequestBody httpd directive to control maximum
length of skel-encoded request bodies.
Justification:
Allow administrators to setup configurable limits on the size of
skel-encoded requests.
Votes:
+1: ivan, rhuijben
* r1691928
Fix issue #4584, "Non-canonical $HOME crashes GPG-agent support code".
Justification:
Regression introduced in 1.8.11. Simple cause; simple fix.
Notes:
Also nominated for 1.9.x.
Trunk has a better fix, but less suitable for backporting, in r1691952.
Votes:
+1: julianfoad
Veto-blocked changes:
=====================
Approved changes:
=================