117
edits
FlightGear Git: splitting FGData: Difference between revisions
Jump to navigation
Jump to search
FlightGear Git: splitting FGData (view source)
Revision as of 21:25, 9 December 2011
, 9 December 2011→Towards a plan
No edit summary |
|||
| Line 64: | Line 64: | ||
* FlightGear's release distributions are steadily increasing in size. With the proposed fgdata split, we should consider removing all aircraft, except the default cessna 172p from the base package. All others can simply be downloaded from the website. Considering that the c172p is and integral part of FlightGear, it should remain the ONLY aircraft that remains in the base package, and wich is is not moved to the new fgaircraft repository. | * FlightGear's release distributions are steadily increasing in size. With the proposed fgdata split, we should consider removing all aircraft, except the default cessna 172p from the base package. All others can simply be downloaded from the website. Considering that the c172p is and integral part of FlightGear, it should remain the ONLY aircraft that remains in the base package, and wich is is not moved to the new fgaircraft repository. | ||
* It should be emphasized that GIT is a distributed revision control system, and that our current use of git is insufficient.Aircraft developers should be encouraged to set up their own personal clone on gitorious, and we should encourage aircraft developers to post more merge requests. | * It should be emphasized that GIT is a distributed revision control system, and that our current use of git is insufficient.Aircraft developers should be encouraged to set up their own personal clone on gitorious, and we should encourage aircraft developers to post more merge requests. | ||
* As more and more people gain commit rights, some rules and guidelines are in order. We currently have a largely unwritten code of conduct that has proven to work well. With new people entering the scene, it will become necessary to put them in writing however. | |||
= A new plan for splitting fgdata = | |||
# Create a new git repository: fgaircraft. This repository will -for the time being- contain all current and new FlightGear aircraft except the default c172p. | |||
# Provide images of the git repository, to alleviate the initial clone problem. Preferably, this should be done using bittorrent, or another interruptable download sourse, so that people with limited bandwith, can monitor their data consuption more flexibly. | |||
# After a few days of testing, remove all aircraft from the main fgdata repository. | |||
# Formalize the status of the new aircraft repositories by formalizing our exisiting, but unwritten, code of conduct and granting new aircraft authors who agree to this code of conduct commit rights. | |||
# Because the new system can allow us to grant a potentially large number of aircraft developers commit access, we deem it desireabe to formulate an explicit set of rules with regard to the contributer's rights and obligations. It should be noted that the following rules are not really new, but merely formalizations of our existing code of conduct. By explicitly formulating them, our main goal is to avoid misunderstanding, and to provide clear guidelines in the unlikely event of misuse of commit rights. | |||
# Post these rule on a relatively prominent location on the main FlightGear.org website. | |||
The rules describing the rights and obligations of committers are as follows: | |||
# Authors who obtain commit rights to fgaircraft retain the rights to handle their own work | |||
# The flightgear fgaircraft administrators are allowed to update aircraft files, but only to enable the use of new features or to fix obvious bugs. | |||
# The flightgear fgaircraft repository maintainers reserve the right to revoke commit access of an individual committer. They can only excersise their right after consensus has been reached among the maintainers, and only in cases of a) misuse of commit rights by the offending developer, or b) prolonged inactivity of the committer (let's say more than a year of inactivity) | |||
# Aircraft that have not been maintained by the prime committer for a prolonged period of time are considered to have been abandoned and may be assigned to a different committer. The major exception to this rule is formed by aircraft that have a high level of completeness that are maintained by committers who are still very active in other areas of FlightGear's development. | |||
# Commit rights will be given after the authors has shown some reasonable level of competence in both aircraft development and GIT usage. While the aircraft developer is still in the process of obtaining the required skills, he or she can seek a mentor who will handle any merge requests. | |||
# If the aircraft developer is uncomfortable in working with git he or she can also opt to choose a "mentor" who will handle the merge requests for them. | |||
# In addition to these rules, anybody contributing to the FlightGear project is encouraged to work with personal clones and submit merge requests. | |||
{{Appendix}} | {{Appendix}} | ||