Howto:Understand the FlightGear development process

This article is a stub. You can help the wiki by expanding it.

The FlightGear development process is described below, with an accessible language and lots of links to Wikipedia for terms you might not know. To learn more, see Release Plan.

Understanding code development

Code development for the unaware

Usually, the process of compiling a program refers to taking its source code (written in some programming language and running it through a so called compiler, which compiles, assembles and links the human readable source code to come up with the resulting binary and executable files, which contain the machine code that can be run by your computer (CPU).

When you simply download a pre-compiled FlightGear release, you do not have to do this yourself, because other people have already done this for you. These are so called release managers, who often also happen to be software developers themselves.

This is because the process of compiling a piece of software such as FlightGear requires a so called build environment which consists of a number of tools (such as a compiler), and custom project configuration settings to turn human readable source code into the machine code that is required for actually running a program.

Programs are usually written in a plain text editor. However, there are very complex "word processors" specifically designed to deal with source code in various programming languages. They are called Integrated development environments or IDEs, because they usually also provide comprehensive integration with the build environment, including its various tools. For example, an IDE may provide integrated support for syntax highlighting, as well as support for running certain commands, i.e. to recompile/rebuild parts of the program (or all of it). In addition, IDEs typically provide support for source code management to access a corresponding respository.

The repository

The human-readable source code is stored on a shared place. It's called generally repository, and FlightGear specifically uses Git (once, CVS). Repositories do not only store code, but allow concurrent contributions without stepping on each other's toes. In very simple terms, all changes to a single piece of code are tracked, so that people can easily look up who made a certain change, or if there were any changes made in a certain time frame (e.g. to prevent conflicts between people working with the same files). Imagine it like a revision history on wikipedia or the FlightGear wiki: for any changes there's someone who's responsible for it, and if several people made conflicting changes, the software will show the difference to merge things easily.

This repository does not store only the FlightGear core project, but also other sister ones, like TerraGear, SimGear and the base package, as well as several related tools.

Normal and core developers

People who build FlightGear from source code and make modifications to this source code, are usually called programmers or more generally developers. People who have commit rights to the master FlightGear Git repository, are called core developers -- because they are the ones who develop the FlightGear "core".

Other programmers/developers may provide patches to the source code, which need to be reviewed, improved and committed by those core developers.

Understanding the base package

The base package contains the data: scenery, aircraft, sounds, images/textures, configuration files, scripts. It has its own section in the main repository.

Most data kept in the base package does not involve any coding/programming, the only exceptions are Nasal scripts and GLSL Shaders. However, none of these require a dedicated build environment, people able to run FlightGear, will automatically have an environment suitable to develop and test Nasal and shaders.

You can contribute to the base package without being a hardcore programmer. See Volunteer.

Configuration files

A configuration file provides a convenient interface to customize a program's behavior without having to be a programmer or developer. Similarly, command line arguments are another way for customizing program behavior without having to change a program's source code.

Imagine it like the difference between a carpenter and someone who merely takes a pre-fabricated piece of furniture (like a chair or table) and customizes it by changing its color, or adding/removing some features. Similarly, just because you are able to refuel your car or change your tyres you would not necessarily be referred to as a "car mechanic".

So, unless you start modifying the source code (logics) of the program (FlightGear) in order to change existing behavior, your changes would normally not qualify as developing, even changing XML files does not fall under development, because XML is a markup (i.e. description) language and not a programming language. To see what's XML used for in FligthGear, visit this article.

Note  To be absolutely fair, some FlightGear XML files do support programming related constructs, especially condition handling via SGCondition, but also the state machine stuff, as well as the autopilot system, the latter providing various building blocks to come up with configurable autopilot components like PID controllers and filters.In addition, FDM development itself is often done via XML files and can be an extremely complex topic, despite not necessarily involving programming in the conventional sense.

Non programming developers

People who do development largely within the confines of the base package (i.e. by creating or modifying aircraft/instruments and/or scenery or other base package resources) are usually also called developers, specifying their area of interest. Terms you'll mostly see here are for example aircraft developer or scenery developer, both of which imply that their work takes usually place in the base package. Some people may refer to them as base package developers or as middlware developers.

This distinction is largely due to the different set of skills required for producing these resources. While programming and software development in general requires dealing with source code of programs in different programming languages, aircraft or scenery development is no longer primarily about programming. These people don't program aircraft or scenery, but usually they design things primarily (i.e. 3D models, textures) and may then add various other resources (such as for example sounds, animations, flight models).

Programming in this context usually refers to tiny scripted programs that are stored in and loaded from the base package, reusable components often provided by others. Programs written in such scripting languages are usually not separately compiled, and can be easily created by people new to programming or software development in general.

Modding, an exception

Of course, you can also literally compile parts (like certain scenery or aircraft) of FlightGear to create a custom version of it. So, someone who simply takes FlightGear, and who creates a custom version of it by downstripping the base package, omitting certain resources and adding new ones or creating custom configurations, would probably not normally be referred to as a "developer" here. The most appropriate term would be modder in that case, because you are "modding" FlightGear to come up with a special version for a specific purpose, without doing any actual "development" like for example C++ coding, Nasal scripting or more generally aircraft/scenery development.

Normally, "developing" something implies changing functionality and logics, in the sense of "programming" and "creating" things, features and code. Someone who customizes a piece of software by editing configuration files and by adding or removing such files would usually not be called a developer.

Developing... documentation

If you were now to start documenting your experiences modding FlightGear, you would become a "contributor" and a "documentation writer" ;-)