FogBugz Integration

| | Comments (15)

It's pretty strange to be happy about a bug reporting system, but I can't help myself! FogBugz really does rock -- I know there are some people who don't care for all of the particulars of it, but trust me when I say that the features it provides really knock the socks off the old feedback system.

I could go on for pages about how awesome it makes our internal processes, and how much time it saves me, etc. But you probably don't care too much about that. Instead, I want to tell you about how awesome it is for you!

We've integrated bug reporting into the IDE to make it trivial for you to enter bug reports about some of the most common error situations you run into. What's more, you have to do almost no work to take advantage of it!

Whenever a bug happens while you're working in the IDE, you'll be presented with a bug reporting dialog that looks like this:

This dialog allows you to enter in some extra information, such as what you were doing when the crash happened, and your email address. It also gives you a link that you can click on to see the report contents, which look something like this:

All you have to do is click Send -- that sends a bug report to us. So why is this so awesome? Well, for starters, it's a significant improvement over the old way you'd have to report the bug. In the old system, you'd have to type out the stack trace yourself (or take a screen shot), and enter in the entire bug report manually. Now you just click a button. But it gets better! All of the identical reports are automatically merged together in FogBugz so that we can see how many people are affected by the same issues. And, even better than that, we can provide instant feedback to users who run into the same issue!

Let's say you have an unhandled exception that fires any time you open up the icon editor. I can enter in a text message within FogBugz that says "We're aware of the issue with the icon editor -- you can work around it by doing X, Y and Z. We hope to have this issue fixed by 2008rX. Thank you for your patience!" Then, whenever someone hits that same bug with the icon editor, they're presented with my friendly message. Annnnnnnd... once the bug is fixed, I can give users a different message, and tell FogBugz to ignore any new reports about the crash. If you'd like to see this particular feature in action, there's a report that is fairly easy to reproduce which demonstrates it (but only if you're using the Mac IDE and have a functional network connection):

1) Make a new project
2) Go into the Menu Editor, and navigate to the File->Quit menu item
3) Change its super from QuitMenuItem to just regular MenuItem
4) Launch the application in the debugger

When you launch the application in the debugger, the IDE should kick the error reporter window up. If you hit the Send button, you should get a response back from the server telling you what the issue might be, and how to resolve it.

So a few things to note about the automated reporter, just for your own education. If you enter an email address into the optional field, then we can communicate directly with you. For instance, when the bug is fixed, you'll get an email letting you know about it. So if you're interested in this sort of communication (which can be very helpful if we need to ask you for more information), then please enter an email address. In terms of what information is sent to our servers: it's all there in the report window. We collect information about whatever we can (and that's subject to change as we determine what helps us to track down bugs) and send it back. Currently, that information is: what plugins are installed, a stack trace, and user-entered data.

Finally, the error reporter pops up for a handful of different error situations. We currently have automatic error reporting for unhandled exception within the IDE, IDE failed assertions, compiler failed assertions, and any framework failed assertions that occur while debugging your application. If any new error reporting situations arise, we will probably add them, because automated reporting saves everyone a ton of time!

So yeah, don't mind me when I'm all giddy about error reporting. But I can assure you, this type of feature was basically impossible with the old feedback system. The switch to FogBugz has made it possible, and it's already saved us a ton of time within the betas program. As an example, there was an assertion in the compiler with the new GetTypeInfo operator -- a user had auto-reported it via the feedback system, and it immediately had enough information for me to go in and resolve the bug. Anyone else who ran into it immediately was told how to work around the bug temporarily, and a fix was forthcoming within a release. Very, very slick!

15 Comments

Actually, I'd be more interested in hearing about how awesome it makes your internal processes; we've been using it for a few years now.

Glad to hear it! I thought that the automatic reply was awesome too.

We have been using FB for sometime ourselves and we love it too.

So when does this get integrated into all RB apps and we can hook it up to our own FogBugz instances? ;-)

@Isaac
You can use RBScoutSubmit, download it from http://code.google.com/p/rbscoutsubmit/

@Aaron
Did you use RBScoutSubmit as the base for your FogBugz error catching?

@Ian -- yes, RBScoutSubmit was the basis, though it's been modified a fair amount to suit our particular needs. Great piece of work!

@Charles -- time will tell, but I can mention that I've already fixed about ten automated reports for issues no one has ever reported before, nine of which have been in the product for more than a single release. The automated reports do a good job of giving us more information than we usually would get for hand-written reports (but, of course, the best automated reports still have more information entered by the poster!). So from that perspective, the auto-reporting has been fantastic.

As for internal processes, we've been using FB since late last year, and it's helped keep us focused very well. It's hard to quantify it in a public blog since it's an internal process though...

I second it. Let's hear about the automation. :D

How about if the automated bug reporter remembered one's email address? It seems like a waste of time to have to enter it for every bug reported.

hmmm .... got a FB report # for that :P

@Isaac -- I agree with Ian, just use his RBScoutSubmit module. It uses a very liberal license, and works really slick!

@Joe -- I think that's an excellent idea! If you enter a report for it (which I recommend you do), please send me an email with the case number.

I think I mentioned it in several of the automated bug reports that I sent in which were NOEs about various remote debugger problems.

I'll go ahead and send in a separate one.

@Ian, @Aaron - sweet, I totally will be putting that into my next RB project

Well, the integrated bug-report system does not cover deadlocks, crashes and most importantly functional bugs and that is 99% we have to deal with.

In the old bug-report system we were at least able to search if other users have the same bug and receive help from them. Now I have to wait and hope REALSoft will ever fix it so that I can deploy my App.

Leave a comment

Disclaimer

I'm currently an employee of REAL Software. My blog is mine. The opinions represented in this blog are mine as well and may not represent my employer's opinions. All original material is copyrighted and property of the author.

REALbasic® is a registered trademark of REAL Software, Inc. REAL SQL Server™ and Lingua™ are pending trademarks of REAL Software, Inc. All rights reserved.