[PATCH] traceback: allow disabling the third party extensions blaming

[Sean Farley]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

> (disclaimer, I'm overall positive with the Matt sugguestion, but have 
> some divergence on some details)
>
> On 09/12/2015 05:42 PM, Matt Mackall wrote:
>> On Fri, 2015-09-11 at 12:58 -0700, Pierre-Yves David wrote:
>>> # HG changeset patch
>>> # User Pierre-Yves David <pierre-yves.david at fb.com>
>>> # Date 1442000719 25200
>>> #      Fri Sep 11 12:45:19 2015 -0700
>>> # Node ID f4cac314b745109687b94808f8802b65b39f2dc9
>>> # Parent  ea489d94e1dc1fc3dc1dcbef1c86c18c49605ed1
>>> traceback: allow disabling the third party extensions blaming
>>>
>>> The extensions blaming code is fine for casual users but pretty terrible for
>>> corporate environments that use a large amount of extensions. For example, all
>>> reports we get from my users always blame crecord, who is never guilty.
>>
>> But it *is* guilty. In particular, it is guilty of being unmaintained
>> and never setting the tested-with field that would take it off the
>> probably-broken list.
>
> Your definition of guilty is kinda wide. We have a large amount of 
> simple and useful third party extensions that are not updated every 
> months. I'm not sure it seems realistic to see their lack of update as 
> critical (even if getting them tested with latest mercurial is one of 
> the goal here).
>
>>
>>>   This
>>> confused users and triggers endless debug attempts from them.
>>
>> You've mistaken this code for a debugging aide. That is not its intent
>> at all. Instead, it exists to reduce the flow of bug reports for
>> third-party extensions that waste the project's scarce time.
>
> The user debugging journey starts with the message.
>
> ** Unknown exception encountered with possibly-broken third-party 
> extension foobar
> ** which supports versions 4.2 of Mercurial.
> ** Please disable foobar and try your action again.
> ** If that fixes the bug please report it to http://foo.bar/bts
>
> The "please disable foobar and try you action again" part definitely 
> lead to users trying to do stuff.
>
>> Ironically, the original primary offender here was Sun developers, who
>> sent us a steady stream of bizarre reports related to their cadmium
>> extension. I do not want to see a steady stream of remotefilelog reports
>> on our BTS from the company that took over their campus.
>>
>> Instead, write a patch that allows site installs to redirect all bug
>> reports to their own support contact. That's a feature we can document.
>
> I like the idea of having a different bugs report flow for big 
> deployment that have there own support layer. We still need to do 
> something about the user confusion and attempt to debug by disabling a 
> long list of extensions one by one.

I have never once gotten anything useful out of the "possibly-broken"
list because it has never been correct. In fact, I've trained myself to
completely ignore it. I'm positive end-users are baffled as well. I like
Pierre-Yves' direction but don't know how to proceed.