Development workflow: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Started with my tale.)
 
(Restructuring; work in progress)
(8 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page outlines some ''first steps'' on how to do (code) development for [[FlightGear]].
{{WIP}}
{{Git}}
This page is meant to be a high-level introduction to the '''development workflow''' of FlightGear, that is, the process developers follow to contribute their work to the project.


=The Big Picture=
== The big picture ==
Everything is stored in several Git ''repositories'' (collection of files) on SourceForge. You can find a list of them in the [[FlightGear Git]] page.


The [[FlightGear]] sources are hosted at Gitorious: https://gitorious.org/fg .
Only a handful of developers have ''commit access'', that is, the right to make changes to those repositories without prior approval. This is done to ensure that only people showing a good, consistent contribution track record and good judgement are able to perform such modifications unsupervised.<ref>[http://www.flightgear.org/flightgear-policy-document FlightGear Policy Document and Roadmap]</ref> For this reason, once a developer contributes some work, it will need to be ''staged'' for approval by another contributor having commit access.


As a safety precaution, the commit access to those repositories is not public and hence development work has to be somewhat ''staged''.
== Life of a patch ==
The contribution process can be divided in the following phases.


Once this staging is done, there are two major possible ways for the done work to find its way back into the official sources:
<!-- TODO: add links to the relevant Wiki pages -->
# '''Clone the repositories you would like to contribute to and fetch them.''' In this context, a ''clone'' is a personal copy of the original repository created for temporarily keeping your proposed modifications until they are accepted into the project. You will need to clone the original repository and download the data to your computer.
# '''Perform the desired modifications''' and publish them to your clone.
# When you are ready to get your work accepted, '''submit a merge request'''. A developer will check your contribution before merging it into the project repositories. Fix any issues that are found during the review.
# Once your work is included, '''monitor the [[FlightGear build server|build server]], the [[Mailing lists|mailing lists]] and the forum''' to check for bugs you might have inadvertently introduced.


# A person with commit access ''OK's'' the work and commits it, using her or his account.
== Scenery and aircraft contributions ==
# A [[GIT Merge Request|merge request]] has been filed and somebody with the proper access performs the merge.
Due (mostly) to their file size, scenery and aircraft are stored using different file management systems and, thus, do not follow the process outlined in this article.
* Scenery contributions should be submitted to the [[FlightGear Scenery Database]].
* Aircraft contributors should follow the instructions given in [[FGAddon]].


Fortunately the ''staging'' necessary for both approaches is essentially the same
== Tips ==
* If you need to take a design decision or want to get some preliminary feedback, ask people on the {{Mailing list e-mail address|flightgear-devel}} mailing list and/or on the forum.


=Using a Personal Gitorious Repository=
{{Appendix}}


'''NOTE:''' This is essentially my tale. AndersG guided me through the process and I wanted to record/report it somewhere. [[User:Hcc23|Hcc23]] 13:59, 19 May 2011 (EDT)
[[Category:Core developer documentation]][[Category:Git]]

Revision as of 21:45, 14 May 2016

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

This page is meant to be a high-level introduction to the development workflow of FlightGear, that is, the process developers follow to contribute their work to the project.

The big picture

Everything is stored in several Git repositories (collection of files) on SourceForge. You can find a list of them in the FlightGear Git page.

Only a handful of developers have commit access, that is, the right to make changes to those repositories without prior approval. This is done to ensure that only people showing a good, consistent contribution track record and good judgement are able to perform such modifications unsupervised.[1] For this reason, once a developer contributes some work, it will need to be staged for approval by another contributor having commit access.

Life of a patch

The contribution process can be divided in the following phases.

  1. Clone the repositories you would like to contribute to and fetch them. In this context, a clone is a personal copy of the original repository created for temporarily keeping your proposed modifications until they are accepted into the project. You will need to clone the original repository and download the data to your computer.
  2. Perform the desired modifications and publish them to your clone.
  3. When you are ready to get your work accepted, submit a merge request. A developer will check your contribution before merging it into the project repositories. Fix any issues that are found during the review.
  4. Once your work is included, monitor the build server, the mailing lists and the forum to check for bugs you might have inadvertently introduced.

Scenery and aircraft contributions

Due (mostly) to their file size, scenery and aircraft are stored using different file management systems and, thus, do not follow the process outlined in this article.

Tips

References