On Wed, Oct 12, 2016 at 10:13 PM, <i...@apache.org> wrote:
> Author: ivan
> Date: Wed Oct 12 20:13:24 2016
> New Revision: 1764536
> URL: http://svn.apache.org/viewvc?rev=1764536&view=rev
> * STATUS: Veto r1759116 group.
> @@ -135,6 +119,24 @@ Candidate changes:
> Veto-blocked changes:
> + * r1759116, r1759117, r1759122, r1759123, r1759124
> + Fix FSFS format 7 packing for revisions packs with lots of changes.
> + Justification:
> + Problem occurred in at least two user repositories. Without the fix,
> + format 7 repositories with an exceptionally large number of changes in
> + a pack cannot be packed - which renders using f7 pointless for those
> + users.
> + Branch:
> + ^/subversion/branches/1.9.x-fsfs-pack-fixes
> + Notes:
> + r1759116 adds a workaround for trunc() corrupting apr_file_t internal
> + r1759117-23 provide the actual fixes.
> + r1759124 adds a regression test with the necessary internal API changes.
> + Votes:
> + +1: stefan2
> + -1: ivan (apr_file_trunc() bug should be reported and fixed in APR,
> + not by unreliable workaround with unknown consequences)
Not picking any side here, but: "should be reported and fixed in APR"
does not sound like a veto-argument to me. It's a valid statement /
request, but not grounds for vetoing a workaround in our code. Perhaps
the bug was already reported to APR and not acted upon (I don't know
and don't really care WRT STATUS), or perhaps it will be reported
later but in the meantime can already be worked around in our code ...
but that's not a problem (we often implement workarounds in our code
for apr problems, and report them to apr, and later switch to the
official apr fix ...).
So that leaves you claiming that it's an "unreliable workaround with
unknown consequences". Why? Please clarify. We are talking about a
bugfix which fixes an important problem reported by users. Do you have
any suggestions for improvement? Perhaps the fix should be technically
discussed on the mailing list? Or should we just leave this important