Improve semi-automatic bug reporting

[Emmanuel Blot]

… before releasing 0.11.

The improved error report generates wikified data that users are not able to report properly on trac.edgewall.org.
This new report leads to badly formatted bug reports, which requires manual fix (time consuming, error prone).

I'm not sure how to fix this problem, but 0.11 should not be released before the error report is improved.

[Christian Boos]

athomas fixed a bug in the semi-automatic error reporting (r5663) and apparently since then, the reports are OK, at least they are how I expect them to be. See #5511 - do you see anything to improve there?

[Christian Boos]

I guess it's mostly OK as it is, but there's one improvement I'd like to see, mainly the list of plugins and their versions in the System Information.

Having this would probably help a lot when dealing with people upgrading to 0.11.

[ThurnerRupert]

its not a bug, so it seems to block 0.11 unecessarily …

[Christian Boos]

It doesn't block 0.11, but it would nevertheless be really useful to have it in time for 0.11, as explained in comment:3. Motivated by #6948 of this morning, I decided to do it. I think we should help people to report plugin failures to their appropriate maintainer, as we have all the relevant information.

This currently doesn't work well for eggs, partly because of a bug in the admin code. So while this is not the final version of the patch, it already works well and provides useful information.

Feedback on attachment:show-enabled-plugins-in-error-page-r6658.diff​ appreciated.

[Christian Boos]

This adds the relevant plugins information to the error page. It also tries to identify the faulty plugins (this part needs to be expanded to handle plugins installed as eggs).

[Christian Boos]

Fixed and improved version of the patch

[Christian Boos]

The new version of the patch (needs r6675) is a greatly enhanced version of the initial patch.

It now properly identifies the culprit plugin if any, even those installed as eggs. If a plugin is involved, the searching link and Create button are not targeting t.e.o's Trac but rather the one indicated by the plugin metadata information (trac entry - I have yet to check if that's possible for eggs) or trac-hacks if the home_page points there.

[Christian Boos]

I'll try to rework the patch to simplify it and focus on identifying which plugin is eventually involved in the backtrace, as this is the really important information and it can't always be deduced by simply looking at the backtrace.

[anonymous]

I would like my customers to automatically report bugs to my Trac system. How do I install this feature on development machine? How is the bug report routed to my location? What happens when the user decides to report the bug?

[Emmanuel Blot]

Replying to anonymous:

I would like my customers to automatically report bugs to my Trac system. How do I install this feature on development machine? How is the bug report routed to my location? What happens when the user decides to report the bug?

About support questions:
Support and installation questions should be asked on the mailing list or IRC channel, not filed as tickets. Also, please check whether the issue you've encountered has been reported before.

[Christian Boos]

Replying to eblot:

About support questions:
Support and installation questions should be asked on the mailing list or IRC channel, not filed as tickets. Also, please check whether the issue you've encountered has been reported before.

Nice start for InstallationIssue ;-)

As for that ticket itself, I'll try to get another version for the next stable release.

[Christian Boos]

Supersedes #2803.

[Remy Blank]

One thing we should also make sure is that people provide an e-mail address when reporting through the error page (be it to t.e.o or a plugin's bug tracker). Otherwise, people tend to just create the ticket and not follow up. Kind of like the crash dialog box in Windowx XP, where you can send the bug report to Microsoft, but you never know what happens with it.

[Remy Blank]

I'll try to refresh this patch after the plugin info refactoring in [9001]. I'd like to at least have plugin information on the error reports for 0.12, maybe even the plugin detection in the traceback.

[Remy Blank]

Plugin version information was added to the error page and to the semi-automatic bug reports in [9002].

[Christian Boos]

Looks good so far! Thanks for carrying this one through.

[Remy Blank]

Detection of faulty plugins and redirection of the bug reports to their Trac instance has been implemented in [9016].

[Christian Boos]

Needed a follow-up for Windows: [9028].

Also, do you think it's worth to keep the full path of the plugin in the table, in the ticket description?

CodeReview	r7457	c:\imagine_a_very_long_path_here_with_no_spaces_or_dashes\trac\devel\plugins\CodeReview.pyc
HellWorld	N/A	c:\imagine_a_very_long_path_here_with_no_spaces_or_dashes\trac\devel\plugins\HellWorld.pyc
HelloWorld	N/A	c:\imagine_a_very_long_path_here_with_no_spaces_or_dashes\trac\devel\plugins\HelloWorld.pyc
…

It's likely going to overflow. We could use the usual trick with zero width spaces, but is this info really necessary for us? I think not, so we could simply remove that column.

In the error page itself, that information is very useful, of course.

[Remy Blank]

Replying to cboos:

Also, do you think it's worth to keep the full path of the plugin in the table, in the ticket description?

(snip)

It's likely going to overflow. We could use the usual trick with zero width spaces, but is this info really necessary for us? I think not, so we could simply remove that column.

I wasn't sure either, so I kept the original functionality. But I still came up with two use cases:

• When a user doesn't remember having installed a plugin.
• When a user has installed a plugin in two different locations (while tinkering), and the one that is active is not the one that she thinks.

In both cases, we could point the user at the installation location. The lines should break at '/' and '\'. But yeah, the overflow is not too nice.

I'm only +0 on keeping the paths. Tell me if you prefer removing them.

[Christian Boos]

I'm for removing the paths in the generated wiki for the ticket description only, as we don't need that information, I think.

As I said, for the user this information is very useful, so no question we should keep the paths in the table displayed in the error page itself. Actually, I would even like to see a Path entry part of each plugin's metadata in the Plugins admin panel…

[Remy Blank]

Will do.

[Remy Blank]

Plugin path information removed from semi-automatic bug reports, and added to "About Trac" in [9030].

[Christian Boos]

Excellent, thanks! (t.e.o updated)

[anatoly techtonik <techtonik@…>]

I have some questions about the patch. It was not convenient to add them here, so I placed them on rietveld ​http://codereview.appspot.com/186050/patch/1/3 It would be nice to get some comments there to test this code review tool.

[Remy Blank]

While Rietveld is a nice tool, I prefer keeping the discussion here, and not depend on external services.

Of course, a Rietveld-like plugin for Trac would be awesome!

[bumstear2@…]

Replying to anonymous:

I would like my customers to automatically report bugs to my Trac system. How do I install this feature on development machine? How is the bug report routed to my location? What happens when the user decides to report the bug?

[stefano.rago]

Is anybody else having problems with the faulty plugin detection on Windows? From what I understand the code that matches the plugins to the frames for the stack trace is replacing the system path separator, but in some cases it doesn't and the detection fails. Any idea?