Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "Development workflow"

From FlightGear wiki
Jump to: navigation, search
(Temporary first version)
(Restructuring; work in progress)
 
Line 4: Line 4:
  
 
== 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.
  
- Code, mailing lists, bug tracker hosted at SourceForge
+
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.
- Commit access: repos not public (see policy)
+
  
 
== Life of a patch ==
 
== Life of a patch ==
- get the repo + fork
+
The contribution process can be divided in the following phases.
- edit (on main for aircraft, on branch for
+
- get feedback for important edits
+
- submit a patch (or direct commit if commit access)
+
- patch applied
+
- check build server and monitor forum+ML
+
  
== Tips ==
+
<!-- TODO: add links to the relevant Wiki pages -->
Ask on ML
+
# '''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.
  
<!--
+
== Scenery and aircraft contributions ==
=The Big Picture=
+
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]].
  
The [[FlightGear]] sources are hosted at SourceForge: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/
+
== 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.
As a safety precaution, the commit access to those repositories is not public and hence development work has to be somewhat ''staged''.
+
 
+
Once this staging is done, there are two major possible ways for the done work to find its way back into the official sources:
+
 
+
# A person with commit access ''OK's'' the work and commits it, using her or his account.
+
# A [[GIT Merge Request|merge request]] has been filed and somebody with the proper access performs the merge.
+
 
+
Fortunately the ''staging'' necessary for both approaches is essentially the same
+
 
+
=Using a Personal Gitorious Repository=
+
 
+
'''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)
+
  
# Create (or login to) a Gitorious account at <nowiki>https://www.gitorious.org/login</nowiki>
+
{{Appendix}}
## If you have a Google account (e.g. Gmail), you can use that to login:
+
## Click ''Or log in with OpenID''
+
## Enter <tt>https://profiles.google.com/yourGoogleLoginName</tt>, replacing <tt>yourGoogleLoginName</tt> with your Google login (i.e. whatever you have in front of @googlemail.com or @gmail.com).
+
  
[[File:Gitorious_cloning_button.png|thumb|400px|The '''Clone repository''' button on <nowiki>https://gitorious.org/fg</nowiki> copies (clones) a Gitorious repository into ones private Gitorious account.]]
+
[[Category:Core developer documentation]][[Category:Git]]
-->
+

Latest revision as of 16: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