It’s very simple: if you want to file a scenery bug, it goes to the bug report form if it is actually a problem with X-Plane or the implementation of X-Plane’s core libraries. If the functionality actually needs to go into WED it goes into the public scenery tools code base, but if it’s a problem with the existing airport data, it goes into the X-Plane Airport Gateway bug database. Plugins have their own bug database. Simple, right?
Given the above, I can’t really be annoyed when authors, developers and users file their bugs in the wrong place. We have five bug databases running now, some public, some private, using three different bug database packages on at least three different servers, implemented in three different back-end languages.
The good news is: Tyler is creating the one bug database to end all bug databases.
Now, if you fly X-Plane and you don’t develop add-ons and you don’t create airports at the airport gateway, I won’t fault you if you don’t care at all. The rest of this post is going to be an (even more) boring discussion of bug databases. Go look at pictures on airliners.net; I won’t fault you for not finishing this post.
For the three of you still here: basically we are creating one unified bug database. The bug database is mostly private (to meet our internal development needs) with a front-end with variable access for authors to contribute. Bugs on some products will remain totally public (e.g. scenery tools), some bugs will private, and there may even be bugs where you can only see what you filed, a la Apple’s “Radar” bug filing system.
Gateway Airport Bugs
This all started when Tyler built a bug report system around the X-Plane airport gateway; it lets you use your airport gateway identity to report bugs on gateway airports. Thus a front-end to a real bug database was born. The front-end lets you have a single user log-in for both uploading airports and reporting bugs.
Scenery Tools Bugs
Tyler has now begun the next step: merging the scenery tools bug database into the new bug database. Thus the scenery tools bug database is temporarily closed to new submissions. All existing bugs will be transferred, but if you don’t have a gateway login you’ll need one to file future bugs.
The scenery tools bugs will remain fully public; the code repository is open source, so the bug base should be as well.
A small number of users have direct access to the scenery tools code repository, e.g. they contributed enough that we gave them their own set of keys. Those users will get direct bug base access as well; however, I think in the long term the front end will include all of the functionality that almost all users will need.
I’m hoping that the migration will be complete within a week or two, and be ready for WorldEditor 1.4 public beta.
Plugin Bugs
The X-plane plugin system has its own bug base; if the scenery tools bug database merge goes well, we’ll merge plugins next. The plugin bug base is a public bug base, like scenery tools, and will probably remain that way.
X-Plane Bugs
I don’t know what we are going to do with X-Plane bugs. The current bug report form does not go directly into our bug base, and I continue to say that that is a good thing: way too high of a percentage of the “bug reports” we get on X-Plane itself look like this:
Help! I just bought X-Plane 10 and it does not work; when I fly I do not see anything! Please help!
Steps to reproduce: Fly the sim!
If you have experience in software quality assurance, you can understand why I don’t want “bugs” like that piling up directly in the bug database; most of the bug reports have to get forwarded to customer support.
You know, if you didn’t write code with bugs you wouldn’t need a database for them.
Just a thought.
I often tell Chris something similar: I have repeatedly told him that if he would just stop using the product he would stop seeing things that are broken. He doesn’t listen…
Yeah, and if it weren’t for the customers/users(/smart-ass blog commenters) it would be perfect.
Thanks for keeping us in the loop. It is truly appreciated.
Great stuff. Yes, I stayed away from the pictures at Airliners.net. I’ve already had my airplane pron fix for the day.
Are we talking a bug report form with radio buttons, Ben? So the user can identify what their real gripe is? What about feature gripes that aren’t really bugs?
I’m all for unification, as long as people can use it, and do. Tyler is a brave soul…
I can see the radio buttons now:
[ ] It doesn’t work!
[ ] WTF!??!
[ ] Help!!!!
[X] I have a crash due to one of my 1000 custom scenery packs.
🙂
Amusing. 🙂
But in a more serious vein, if you have one database for all manner of bugs and perhaps feature requests, that suggests some sort of single point of entry. How will this work for those reporting a bug of any sort?
We haven’t decided yet. But there may be multiple entry points, e.g. if you are looking at a scenery pack, having a report option _right on that pack_ that can capture which pack it was is a win. So there can be multiple portals into one system.
What about getting the bugs into the database through the form – but automatically assigning them to the Customer Support Team for Review?
Best of both worlds… 🙂
“I don’t know what we ware going to do with X-Plane bugs.”
I’ve just noted a typo. In which database do I file a bug report? /grin
HOW MANY TIMES DO I HAVE TO WRITE THIS!??! FILE! A! BUG!!!!!!!!!!!!
I kid. 🙂 Fixed, thanks!
(Clearly we need a 6th bug base for the blog…;-)
Wow – I never knew about airliners.net! Thanks for the tip, there Ben.
Apart from that, I’m always pleased to hear about the progress you’re making. Keep up the good work, and thanks for blogging.
Well I have a fly that keeps bugging me while flying….is there a report spot for that…..I know it is X-planes fault somehow……
I kid…..
All sounds like a smooth plan.
Where’s the best place to report bugs & feature requests for the X-Plane iOS app? Not just iTunes, I hope! I didn’t see a category for mobile apps on the bug reporter form linked at the top of this page.
For iOS: info@x-plane.com