2012-12-09 08:56:51 +00:00
|
|
|
# Contributing to RetroArch
|
|
|
|
|
|
|
|
|
|
If you are a developer and want to contribute to the development of RetroArch, please read this.
|
2012-12-09 09:03:52 +00:00
|
|
|
If you have found a bug and want to submit a minor patch or a bug report, please read this as well.
|
|
|
|
|
|
|
|
|
|
# Submitting a bug report
|
|
|
|
|
When submitting a bug report, make sure that the bug is local to RetroArch.
|
|
|
|
|
A bug in a libretro core or something deemed to be external is likely to be closed very fast.
|
|
|
|
|
If you still suspect a bug in RetroArch, make sure to test with several cores to make sure.
|
|
|
|
|
|
|
|
|
|
If you have troubles building RetroArch on Linux/BSD/OSX, make sure to paste shell output of ./configure,
|
|
|
|
|
as well as config.log and shell output of make. If building on Windows, just paste shell output of make.
|
|
|
|
|
|
|
|
|
|
If the issue occurs during runtime, make sure to paste RetroArch's verbose log.
|
|
|
|
|
If using Phoenix frontend, you can find log in (File -> Show Log) after running.
|
|
|
|
|
In console, make sure to run with verbose (-v) flag.
|
2012-12-09 08:56:51 +00:00
|
|
|
|
|
|
|
|
# Pull Requests
|
|
|
|
|
Outside contributions are generally only accepted in the form of a pull request. The process is very simple.
|
|
|
|
|
Fork RetroArch, make your changes, and issue a pull request on GitHub. This can all be done within the browser.
|
|
|
|
|
The changes are reviewed, and might be merged in. If the pull request isn't acceptable at the time,
|
|
|
|
|
note that it's possible to continue pushing up commits to your branch.
|
|
|
|
|
|
|
|
|
|
If you want to develop a larger feature,
|
|
|
|
|
we'd like to discuss this first (ideally on IRC) so that you don't risk developing something
|
|
|
|
|
that won't be merged. A pull request with a proof-of-concept is fine, but please indicate so.
|
|
|
|
|
|
|
|
|
|
# Coding style
|
|
|
|
|
Having a consistent code style throughout the code base is highly valued.
|
|
|
|
|
Please look through the code to get a feel for the coding style.
|
|
|
|
|
A pull request may be asked to fix the coding style before submission.
|
|
|
|
|
In other cases, a pull request may be followed up with a "style nit commit".
|
|
|
|
|
|
|
|
|
|
# Copyright Headers and AUTHORS
|
|
|
|
|
If you have contributed to a part of a source file (a chunk of code that's written by you),
|
|
|
|
|
you should add yourself to the copyright header in that file.
|
|
|
|
|
If you have contributed significantly
|
|
|
|
|
(a feature, a contribution you can "name", e.g. "Added audio driver foo"), you should add yourself to AUTHORS file.
|
|
|
|
|
We'd like your full name and email, and which features you have been part of.
|
|
|
|
|
|
|
|
|
|
# IRC
|
|
|
|
|
Active development happens on IRC. (#retroarch @ irc.freenode.org)
|
|
|
|
|
We value discussing things in "real-time".
|
|
|
|
|
|
|
|
|
|
# Commit Access
|
|
|
|
|
Contributors who show a track record of making good pull requests over time will eventually get commit access to the repo.
|
|
|
|
|
This typically happens when the "overhead" of looking through pull requests over time becomes a burden.
|
