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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Mon Sep 14 10:53:38 CDT 2015


(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.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list