How the FlightGear project works: Difference between revisions

Jump to navigation Jump to search
bug priorities: http://forum.flightgear.org/viewtopic.php?f=18&t=23063&p=209595#p209532
m (+-cat FG -> Community)
(bug priorities: http://forum.flightgear.org/viewtopic.php?f=18&t=23063&p=209595#p209532)
Line 102: Line 102:


In addition, FlightGear itself has been a moving target with a constant stream of new features and enhancements some of which require changes to at least some aircraft.
In addition, FlightGear itself has been a moving target with a constant stream of new features and enhancements some of which require changes to at least some aircraft.
== Priorities in bug fixing ==
<blockquote>
I stopped filing bug reports after too many instances of our omniscient developers denying a problem exists, or telling me to fix it myself (yeah, right). Bug reports are a waste of time. You'll have a hard time convincing me that anyone cares about fixing bugs that don't bother them personally. I'm really glad some folks are writing free software for me, but you gotta admit, most of them are pretty arrogant about it.
</blockquote>
Let's start this with the obvious - how much of your free time do you invest into things which don't bother you personally? Do you volunteer for 3 hours per week to make the world a better place? Because preciously few do, whereas the average FG developer does.
For a bug to be fixed it takes the coincidence of a few factors:
# Attention - someone who has the ability to fix it must know about it
# Relevance - that person must judge it worth his time
# Information - that person must either be able to reproduce it or be given enough information
# Access - someone needs to commit the fix to the repository
If you tell me that you find that you get a shader compilation error of someshader.frag in line 401, you have covered 1) (told the right person), and 2) (we shouldn't have shader compilation errors) and 3) (I have all I need to fix it, a line number is as good as it gets) and since I have 4) covered myself, you'll see a fix overnight.
Sadly, that's not how bugs are usually reported. They're told to the wrong person with insufficient information given, follow-up requests for more information are ignored, and as a result nothing happens. Because I'm not going to spend hours guessing what people might be doing such that a problem becomes visible if I can't reproduce it, and neither is anyone else I know. Arrogance is to expect users have the right to such a chunk of developer's time and hence feel they shouldn't need to be asked for more info and to do checks.
Relevance stalls another bunch. The time of core-developers like Stuart or James (who do a hell lot of unpleasant bug-fixing) is precious - if they work on fixing something for 5 hours, I'd rather have them fix something important. Relevant things get priorized. If I judge a problem relevant which I can't fix, I gather enough information to make it easy to find the cause and then ask someone to look at it. TACAN got fixed within a day, lack of solidity of the carrier within a week. These are flight-critical, spawning on the carrier upon reset is not, it's a luxury - the sim can be operated just fine without the ability to reset and we could simply disable it.
Access stalls a fix really rarely - only if there is concern that the patch might have unwanted side-effects.
Also, in a fair share of situations, the problem is with the user or his system. A number of 'FG doesn't run' reports have to do with users messing up paths on their system during re-installing something. Many 'AP is broken' reports really are improper usage of correctly modeled systems (I'm guilty of that one myself in two instances). If FG has a problem only on your computer, it's unlikely to be a problem of FG. And so on. Of course, all users 'know' that the problem can't possibly be on their side...


== Number of aircraft vs. quality of aircraft ==
== Number of aircraft vs. quality of aircraft ==
573

edits

Navigation menu