Board index FlightGear Support

Making bug reports

All general support: help on flying, installation, hardware, getting online etc. There are lots of users and developers to help you out.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- where did you download your aircraft/scenery from?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Making bug reports

Postby Hooray » Fri Dec 03, 2010 4:08 pm

Please don't post bug reports to the forum, instead use the official bug tracker: http://flightgear-bugs.googlecode.com/
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 10751
Joined: Tue Mar 25, 2008 8:40 am

Re: Making bug reports

Postby Tuxklok » Fri Dec 03, 2010 5:25 pm

On a related note, for those not subscribed to the developers list...

James wrote:There's a release looming, and it would be great if it had fewer bugs than the last one. To help with that, there's many thing you (yes, you!) can do:

http://code.google.com/p/flightgear-bugs/issues/list

- file bugs if they're not in the tracker - even if they're widely discussed on the forums, don't assume anyone reads those.

- review bugs marked as 'testing' - this indicates that the bug can't be fixed without help, eg graphics card problems, platform bugs, or things that can't be reproduced by some people. Positive and negative results are useful, if it helps to narrow down why the bug only happens for some people.

- review open and unassigned bugs - eg if you think there's a duplicate, or more information required, or if a particular developer should be CC-d on an issue. I do this periodically, but more eyes would be better. And obviously if you file a bug, keep an eye on it.

- run nightly builds, or Git builds, and test (and then file bugs!) - ideally keeping a copy of 2.0 working to compare behaviours / performance / anything else.

- pick a bug tagged as 'fixable', and have a go! This is the tag I'm using for things that can be fixed without deep knowledge of all of FG - the hope being to have a supply of things for coders new to FG to get a taste. (Not many of these at the moment, unfortunately)

Note we're mostly keeping aircraft-specific bugs out of the tracker, but there are some in there - the same for scenery data bugs. If you're not sure if something should be filed, ideally check if it's specific to one aircraft, and if not, file it.

Regards,
James


So yeah, grab a nightly or build your own and help test, and report those bugs in the right place.

cheers
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1326
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux


Return to Support

Who is online

Users browsing this forum: No registered users and 1 guest