asgardius/Ryujinx
1
0
Fork 0
mirror of https://github.com/GreemDev/Ryujinx synced 2024-11-21 09:30:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fix a couple dead links and spotty wording in docs (#260)
Some checks failed
Canary release job / Create tag (push) Has been cancelled
Details
Canary release job / Release for linux-arm64 (push) Has been cancelled
Details
Canary release job / Release for linux-x64 (push) Has been cancelled
Details
Canary release job / Release for win-x64 (push) Has been cancelled
Details
Canary release job / Release MacOS universal (push) Has been cancelled
Details

Browse source 
Made it clearer that building is for contributors only in `COMPILING.md`

Fixed 2 dead links in `CONTRIBUTING.md`, that were caused by separating
`COMPILING.md` and file structure changed to `pr-guide.md`
This commit is contained in:
GabCoolGuy 2024-11-17 11:35:37 +01:00 committed by GitHub
parent 2e1ede5348
commit 25d69079cb
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
COMPILING.md
View file

@ -1,6 +1,6 @@
## Compilation ## Compilation
Building the project is for advanced users. Building the project is for users that want to contribute code only.
If you wish to build the emulator yourself, follow these steps: If you wish to build the emulator yourself, follow these steps:
### Step 1 ### Step 1
@ -20,4 +20,4 @@ Then type the following command: `dotnet build -c Release -o build`
the built files will be found in the newly created build directory. the built files will be found in the newly created build directory.
Ryujinx system files are stored in the `Ryujinx` folder. Ryujinx system files are stored in the `Ryujinx` folder.
This folder is located in the user folder, which can be accessed by clicking `Open Ryujinx Folder` under the File menu in the GUI. This folder is located in the user folder, which can be accessed by clicking `Open Ryujinx Folder` under the File menu in the GUI.

4
CONTRIBUTING.md
View file

@ -74,7 +74,7 @@ We use and recommend the following workflow:
3. In your fork, create a branch off of main (`git checkout -b mybranch`). 3. In your fork, create a branch off of main (`git checkout -b mybranch`).
- Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork.
4. Make and commit your changes to your branch. 4. Make and commit your changes to your branch.
- [Build Instructions](https://github.com/GreemDev/Ryujinx#building) explains how to build and test. - [Build Instructions](https://github.com/GreemDev/Ryujinx/blob/master/COMPILING.md) explains how to build and test.
- Commit messages should be clear statements of action and intent. - Commit messages should be clear statements of action and intent.
6. Build the repository with your changes. 6. Build the repository with your changes.
- Make sure that the builds are clean. - Make sure that the builds are clean.
@ -83,7 +83,7 @@ We use and recommend the following workflow:
- State in the description what issue or improvement your change is addressing. - State in the description what issue or improvement your change is addressing.
- Check if all the Continuous Integration checks are passing. Refer to [Actions](https://github.com/GreemDev/Ryujinx/actions) to check for outstanding errors. - Check if all the Continuous Integration checks are passing. Refer to [Actions](https://github.com/GreemDev/Ryujinx/actions) to check for outstanding errors.
8. Wait for feedback or approval of your changes from the core development team 8. Wait for feedback or approval of your changes from the core development team
- Details about the pull request [review procedure](docs/workflow/ci/pr-guide.md). - Details about the pull request [review procedure](docs/workflow/pr-guide.md).
9. When the team members have signed off, and all checks are green, your PR will be merged. 9. When the team members have signed off, and all checks are green, your PR will be merged.
- The next official build will automatically include your change. - The next official build will automatically include your change.
- You can delete the branch you used for making the change. - You can delete the branch you used for making the change.

2
docs/workflow/pr-guide.md
View file

@ -9,7 +9,7 @@ To merge pull requests, you must have write permissions in the repository.
## Quick Code Review Rules ## Quick Code Review Rules
* Do not mix unrelated changes in one pull request. For example, a code style change should never be mixed with a bug fix. * Do not mix unrelated changes in one pull request. For example, a code style change should never be mixed with a bug fix.
* All changes should follow the existing code style. You can read more about our code style at [docs/coding-guidelines](../coding-guidelines/coding-style.md). * All changes should follow the existing code style. You can read more about our code style at [docs/coding-style](../coding-guidelines/coding-style.md).
* Adding external dependencies is to be avoided unless not doing so would introduce _significant_ complexity. Any dependency addition should be justified and discussed before merge. * Adding external dependencies is to be avoided unless not doing so would introduce _significant_ complexity. Any dependency addition should be justified and discussed before merge.
* Use Draft pull requests for changes you are still working on but want early CI loop feedback. When you think your changes are ready for review, [change the status](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request) of your pull request. * Use Draft pull requests for changes you are still working on but want early CI loop feedback. When you think your changes are ready for review, [change the status](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request) of your pull request.
* Rebase your changes when required or directly requested. Changes should always be commited on top of the upstream branch, not the other way around. * Rebase your changes when required or directly requested. Changes should always be commited on top of the upstream branch, not the other way around.