FlightGear Git: splitting FGData: Difference between revisions

Jump to navigation Jump to search

FlightGear Git: splitting FGData (view source)

Revision as of 21:53, 9 December 2011

No change in size ,  9 December 2011
m
→‎A new plan for splitting fgdata: fixed some typos only
m (→‎A new plan for splitting fgdata: fixed some typos only)
Line 69: Line 69:


# Create a new git repository: fgaircraft. This repository will -for the time being- contain all current and new FlightGear aircraft except the default c172p.
# 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.  
# Provide images of the git repository, to alleviate the initial clone problem. Preferably, this should be done using bittorrent, or another interruptable download source, so that people with limited bandwidth, can monitor their data consumption more flexibly.  
# After a few days of testing, remove all aircraft from the main fgdata repository.
# 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.  
# Formalize the status of the new aircraft repositories by formalizing our existing, 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.  
# 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 contributor'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.  
# 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:
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
# 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 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)
# The FlightGear fgaircraft repository maintainers reserve the right to revoke commit access of an individual committer. They can only exercise 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.  
# 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.
# 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.
ThorstenB
159

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/37742"

Navigation menu