|
It would also be very useful to get feedback from python asserts --
i.e. the asserts most of us add to the Chandler code. Today the release
version of Chandler ignores all asserts. John Heikki Toivonen wrote: I've been working on a talkback-like functionality for Chandler. (Talkback is a proprietary crash reporting system used for example by Mozilla. You can query the public data here: http://talkback-public.mozilla.org/search/start.jsp) We'd need a different name than talkback so suggestions welcome...Although the original talkback is about reporting hard crashes with C/C++ stack traces, the Chandler feedback mechanism is intended to enable users to report uncaught Python tracebacks with additional system etc. info. (I think I saw mention that wxWidgets has some crash reporting system in place as well but I haven't researched further.) I have the client side code pretty much done expect for the lines of code that actually send the report. I recently saw mention that people have done these for webapps as well (http://www.fogcreek.com/FogBUGZ/help/UsingFogBUGZtoGetCrashRep.html), which is why I decided to cross-post to cosmo and scooby lists in case there is some interest. Jared and I have been thinking a little bit about the server side, and now would be good time to get some feedback on that. We think most reliable way, and easiest to implement both client and server side and operate on the server side would be to use http (or perhaps https) to communicate the feedback. We'd like to start simple. In fact as simple as just using HTTP POST to send a single text file. I guess we are not sure if we'd prefer simple XML or just plain text. Plain text would be easy to grep etc., but there are some things in the feedback that span several lines which makes XML more attractive (user comments, traceback, ...). With the right kind of XML most of plain text file benefits could still be achieved. We could handle different applications and application versions by posting to different URLs. Depending on how many reports we get, we might need to batch process the reports into database and/or index them with some text search system. Another alternative would also be to start discarding reports after a certain period of time or certain number of reports - after all the most valuable reports tend to come in soon after a release. We'd then have simple query/display app where you could search by incident id, stack signature etc. or perhaps by regex. Due to privacy concerns we may want to limit the full reports to OSAF staff, but showing stack info etc. should be free for all. I should be possible to associate reports with bugs. By the way, all of this server side stuff would also be open source. With the simplest possible solutions we could get the server side up in a day. So, any interest? Suggestions? Reply-To set to general. |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "General" mailing list http://lists.osafoundation.org/mailman/listinfo/general
