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
Users browsing this forum: No registered users and 1 guest