On 13.12.2018 17:39, Mark Phippard wrote:
>> On Dec 13, 2018, at 11:26 AM, Branko Čibej <brane_at_apache.org> wrote:
>>
>> On 13.12.2018 17:09, Mark Phippard wrote:
>>>> On Dec 13, 2018, at 10:53 AM, Michael Pilato <cmpilato_at_collab.net> wrote:
>>>>
>>>>> On 12/13/18 10:45 AM, Branko Čibej wrote:
>>>>> Uh. I forgot about the malfunction handler. However this doesn't really
>>>>> help, other than putting possibly sensitive paths into the crash handler
>>>>> info? We really shouldn't do it this way, users *will* just copy and
>>>>> paste the output tot he 'net.
>>>> Ahem. What Grandpa *meant* to say was:
>>>>
>>>> "Oh, cool! So there _is_ a way to report the non-canonical path.
>>>> Thanks for figuring this out, Julian! Unfortunately, it comes at a
>>>> cost, namely that of revealing potentially sensitive paths in the output
>>>> which I strongly suspect will get copied and paste to the 'net. If we
>>>> could mitigate that part of it, this might turn out to be truly beneficial."
>>>>
>>>> ;-)
>>> Honestly, it seems like complete FUD to me and trying to save face or just be obstinate.
>>>
>>> FWIW, I agree with Stefan on all of this. We should not be doing abort from a library. Whether TSVN could do more to avoid it seems like a separate issue. I do not see why the library cannot just return a useful error and allow the caller to handle it.
>>
>> Backwards compat dictates that we can't change the signatures of those
>> functions. We can write new ones with different signatures and deprecate
>> the old ones.
>>
>>
>> Or rather "they" because I'm not volunteering for the code churn and
>> related backporting fallout. That's not stopping anyone else from having
>> a go.
>>
> Fair enough. I have largely stayed out of the conversation for the same reason ... I am not offering to help with the effort.
>
> It is good to hear you are not necessarily opposed to someone doing this work because I was under the impression you would try to block those changes.
I never said that it's a good idea to abort in a library. We made a
mistake in the early days of this project to allow such patterns.
I am quite angry at the contrariness and stubbornness of one TSVN
developer, who is *also* a Subversion PMC member. He could have proposed
changes or fixed those functions years ago. Instead its always "you
should fix this" and "you should fix that", when it's his project, too.
WTF? Am I the only one who finds this to be really bad form?
-- Brane
Received on 2018-12-13 18:00:07 CET