Development workflow: Difference between revisions
Jump to navigation
Jump to search
m (remove HCC23's WIP notice) |
(Restructuring; work in progress) |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{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 == | |||
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.<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. | |||
The | == Life of a patch == | ||
The contribution process can be divided in the following phases. | |||
<!-- 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. | |||
== 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. | |||
* Scenery contributions should be submitted to the [[FlightGear Scenery Database]]. | |||
* Aircraft contributors should follow the instructions given in [[FGAddon]]. | |||
== 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. | |||
{{Appendix}} | |||
[[Category:Core developer documentation]][[Category:Git]] | |||
[[ | |||
Revision as of 21:45, 14 May 2016
 |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
| Git |
|---|
|
Git is a version control system, used to store all files required to build FlightGear. |
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.
- 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 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.
- Scenery contributions should be submitted to the FlightGear Scenery Database.
- Aircraft contributors should follow the instructions given in FGAddon.
Tips
- If you need to take a design decision or want to get some preliminary feedback, ask people on the flightgear-devel@lists.sourceforge.net mailing list and/or on the forum.
| References |