Difference between revisions of "Getting Your Pull Accepted"
imported>Cheridan (not all bugfix only prs are given amnesty) |
imported>Cheridan (Changes the tone of the page from first person, "we we we") |
||
| Line 1: | Line 1: | ||
'''Work in progress...''' | '''Work in progress...''' | ||
| − | So you've made a change to the code/sprites and want to make a Pull Request so | + | So you've made a change to the code/sprites and want to make a Pull Request so it can be added to the game! |
| − | Before you do this, though, | + | Before you do this, though, there are have some requirements so your code doesn't make SS13's infamous spaghetti code problems even worse. Make sure your code fits these requirements or your pull will not be accepted. You may also want to read through the suggestions section. |
== Pull Request Requirements == | == Pull Request Requirements == | ||
=== 1. Your code MUST compile. === | === 1. Your code MUST compile. === | ||
| − | This is a given. While | + | This is a given. While your pull request will not be closed over this, it will not be accepted until it does compile cleanly. The [https://travis-ci.org/tgstation/-tg-station Travis] bot will check for this automatically, but you should check before you even commit. Warnings should also be cleared. |
=== 2. You MUST follow the coding standards === | === 2. You MUST follow the coding standards === | ||
| Line 14: | Line 14: | ||
=== 3. Do not automatically add FILE_DIR. === | === 3. Do not automatically add FILE_DIR. === | ||
| − | A recurring problem | + | A recurring problem is people adding commits that needlessly spam changes to the DME due to having "Automatically add FILE_DIR" set in their project settings. You'll know if you have this problem if you see this in your commit (as seen through github): |
| − | [[Image:Fucking_FILE_DIR.png| | + | [[Image:Fucking_FILE_DIR.png|600px|center]] |
PRs that add things to FILE_DIR will be rejected. | PRs that add things to FILE_DIR will be rejected. | ||
| Line 33: | Line 33: | ||
=== 5. Clearly State What Your Pull Request Does, All Of It === | === 5. Clearly State What Your Pull Request Does, All Of It === | ||
| − | Please do NOT withhold information about your pull request | + | Please do NOT withhold information about your pull request. This will get your pull request delayed, and if it happens too often your pull request will be closed. |
Suppose you fixed bug #1234 and changed the name and description of an item as a gag. | Suppose you fixed bug #1234 and changed the name and description of an item as a gag. | ||
Revision as of 14:11, 3 October 2014
Work in progress...
So you've made a change to the code/sprites and want to make a Pull Request so it can be added to the game!
Before you do this, though, there are have some requirements so your code doesn't make SS13's infamous spaghetti code problems even worse. Make sure your code fits these requirements or your pull will not be accepted. You may also want to read through the suggestions section.
Pull Request Requirements
1. Your code MUST compile.
This is a given. While your pull request will not be closed over this, it will not be accepted until it does compile cleanly. The Travis bot will check for this automatically, but you should check before you even commit. Warnings should also be cleared.
2. You MUST follow the coding standards
Please read through these Coding_Standards. The standards will change over time. Hopefully you already read through and made sure your code adhered to them before opening your pull request!
3. Do not automatically add FILE_DIR.
A recurring problem is people adding commits that needlessly spam changes to the DME due to having "Automatically add FILE_DIR" set in their project settings. You'll know if you have this problem if you see this in your commit (as seen through github):
PRs that add things to FILE_DIR will be rejected.
To fix this problem:
- Open up DreamMaker
- Build > Preferences for tgstation.dme...
- Uncheck "Automatically set FILE_DIR for sub-directories"
- Check compile.
- Close DreamMaker and commit again.
4. Pull Requests Must Be Atomic
Pull requests must add, remove, or change only ONE feature or related group of features. Do not "bundle" together a bunch of things, as each change may be controversial and hold up everything else. In addition, it's simply neater.
Bugfix-only PRs are granted some leniency, however not all bugfixes are made equal. It's possible to have a change that technically fixes a bug, but does so in a way that's hacky or otherwise undesirable.
5. Clearly State What Your Pull Request Does, All Of It
Please do NOT withhold information about your pull request. This will get your pull request delayed, and if it happens too often your pull request will be closed.
Suppose you fixed bug #1234 and changed the name and description of an item as a gag.
Bad:
In this PR I fixed bug #1234.
Acceptable:
In this PR I fixed bug #1234 and also modified the baton's name and description.
