159
edits
FlightGear Git: splitting FGData: Difference between revisions
Jump to navigation
Jump to search
FlightGear Git: splitting FGData (view source)
Revision as of 22:12, 9 December 2011
, 9 December 2011→A new plan for splitting fgdata
m (→A new plan for splitting fgdata: fixed some typos only) |
|||
| Line 76: | Line 76: | ||
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 | ||
# 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 | ## to enable the use of new FlightGear features (such as adding a necessary include file or set a few property switches), | ||
# 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 | ## to fix small and obvious bugs (such as fixing a misspelled property or file name), or | ||
# Commit rights will be given after the authors | ## to apply changes necessary to keep aircraft compatible with an upcoming FlightGear release. | ||
# If the aircraft developer is uncomfortable in working with | # 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 | ||
# In addition to these rules, anybody contributing to the FlightGear project is encouraged to work with personal clones and submit merge requests. | ## misuse of commit rights by the offending developer, or | ||
## 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 obvious 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 have shown a 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}} | ||