Advertise with Googlier.com https://blog.liw.fi/tag/debug/ blog.liw.fi ikiwiki Sun, 22 Jan 2017 15:50:44 +0000 https://blog.liw.fi/posts/2017/01/22/improving_debugging_via_email_followup/ https://blog.liw.fi/posts/2017/01/22/improving_debugging_via_email_followup/ debug Sun, 22 Jan 2017 17:35:00 +0000 2017-01-22T15:50:44Z <p>Half a year ago I wrote a blog post about <a href="https://blog.liw.fi/posts/debugging-over-email/">debugging over email</a>. This is a follow-up.</p> <p>The blog post summarised:</p> <ul> <li><p>Have an automated way to collect all usual informaion needed for debugging: versions, config and log files, etc.</p></li> <li><p>Improve error messages so the users can solve their issues themselves.</p></li> <li><p>Give users better automated diagnostics tools.</p></li> </ul> <p>Based on further thinking and feedback, I add:</p> <ul> <li><p>When a program notices a problem that may indicate a bug in it, it should collect the necessary information itself, automatically, in a way that the user just needs to send to the developers / support.</p></li> <li><p>The primary goal should be to help people solve their own problems.</p></li> <li><p>A secondary goal is to make the problem reproducible by the developers, or otherwise make it easy to fix bugs without access to the original system where the problem was manifested.</p></li> </ul> <p>I've not written any code to help with this remote debugging, but it's something I will start experimenting with in the near future.</p> <p>Further ideas welcome.</p> https://blog.liw.fi/posts/debugging-over-email/ https://blog.liw.fi/posts/debugging-over-email/ debug Tue, 19 Jul 2016 14:57:36 +0000 2016-07-19T15:07:58Z <p>I write free software and I have some users. My primary support channels are over email and IRC, which means I do not have direct access to the system where my software runs. When one of my users has a problem, we go through one or more cycles of them reporting what they see and me asking them for more information, or asking them to try this thing or that thing and report results. This can be quite frustrating.</p> <p>I want, nay, need to improve this. I've been thinking about this for a while, and talking with friends about it, and here's my current ideas.</p> <p>First idea: have a script that gathers as much information as possible, which the user can run. For example, log files, full configuration, full environment, etc. The user would then mail the output to me. The information will need to be anonymised suitably so that no actual secrets are leaked. This would be similar to Debian's package specific reportbug scripts.</p> <p>Second idea: make it less likely that the user needs help solving their issue, with better error messages. This would require error messages to have sufficient explanation that a user can solve their problem. That doesn't necessarily mean a lot of text, but also code that analyses the situation when the error happens to include things that are relevant for the problem resolving process, and giving error messages that are as specific as possible. Example: don't just fail saying "write error", but make the code find out why writing caused an error.</p> <p>Third idea: in addition to better error messages, might provide diagnostics tools as well.</p> <p>A friend suggested having a script that sets up a known good set of operations and verifies they work. This would establish a known-working baseline, or smoke test, so that we can rule things like "software isn't completely installed".</p> <p>Do you have ideas? Mail me (liw@liw.fi) or tell me on identi.ca (@liw) or Twitter (@larswirzenius).</p>