Skip to content

Latest commit

 

History

History
78 lines (59 loc) · 3.54 KB

CONTRIBUTING.md

File metadata and controls

78 lines (59 loc) · 3.54 KB
Raw

Content Guidelines

The issue tracker is exclusively for filing and discussing bugs, feature requests, and tracking work items. It is not for technical support or general discussion. Avoid discussing any illegal activity, such as downloading games.

Repeated misuses will result in a permanent project ban.

Information Sourcing

All information in xenia has been derived from reverse engineering legally-owned games, hardware, and tools made public by Microsoft (such as the XNA Game Studio tooling), scouring documentation made public by Microsoft (such as slide decks and other presentations at conferences), and information from code made public by 3rd party companies (like the Valve SDKs).

The official Microsoft Xbox Development Kits (XDKs) are not to be used for any information added to the project. The contributors do not want the XDKs, nor do they want any information derived from them. The challenge of the project is what makes it fun! Poisoning the codebase with code obtained by shady means could result in the project being terminated, so just don't do it.

Posting any information directly from an XDK will result in a project ban.

Contributing Code

Style Guide

Please read over style_guide.md before sending pull requests and ensure your code is clean as the buildbot (or I) will make you to fix it :) style_guide.md has information about using xb format and various IDE auto formatting tools so that you can avoid having to clean things up later, so be sure to check it out.

Basically: run xb format before you add a commit and you won't have a problem.

Clean Git History

Tools such as git bisect are used on the repository regularly to check for and identify regressions. Such tools require a clean git history to function properly. Incoming pull requests must follow good git rules, the most basic of which is that individual commits add functionality in somewhat working form and fully compile and run on their own. Small pull requests with a single commit are best and multiple commits in a pull request are allowed only if they are kept clean. If not clean, you will be asked to rebase your pulls (and if you don't know what that means, avoid getting into that situation ;).

Example of a bad commit history:

  • Adding audio callback, random file loading, networking, etc. (+2000 lines)
  • Whoops.
  • Fixing build break.
  • Fixing lint errors.
  • Adding audio callback, second attempt.
  • ...

Histories like this make it extremely difficult to check out any individual commit and know that the repository is in a good state. Rebasing, cherry-picking, or splitting your commits into separate branches will help keep things clean and easy.

License

All xenia code is licensed under the 3-clause BSD license as detailed in LICENSE. Code under third_party/ is licensed under its original license.

Incoming code in pull requests are subject to the xenia LICENSE. Once code comes into the codebase it is very difficult to ever fully remove so copyright is ascribed to the project to prevent future disputes such as what occurred in Dolphin. That said: xenia will never be sold, never be made closed source, and never change to a fundamentally incompatible license.

Any third_party/ code added will be reviewed for conformance with the license. In general, GPL code is forbidden unless it is used exclusively for development-time tooling (like compiling). LGPL code is strongly discouraged as it complicates building.