On 12 October 2016 at 22:30, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Oct 12, 2016 at 10:13 PM, <ivan_at_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
>> Log:
>> * STATUS: Veto r1759116 group.
>>
>> Modified:
>> subversion/branches/1.9.x/STATUS
> ...
>> @@ -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 state.
>> + 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)
>> +
>
[...]
> 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
> problem unfixed?
I think it's almost always better to solve the problem in its origin.
Any workaround is unreliable, so we should always try to fix the
problem at the root before trying the workarounds. Note that we are
talking about a relatively obvious bug in other Apache's project, not
about something irrecoverable.
As far as I know, this problem has never been reported to the APR's
dev list. And this is the first action that we should have done.
> Do you have any suggestions for improvement?
I have plans to send a patch to APR in order to solve this problem. So
we don't need to release this workaround.
--
Ivan Zhakov
Received on 2016-10-13 13:23:21 CEST