diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 13ce2b556..e63e27922 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,6 +1,6 @@ -# Contribution to Ryujinx +# Contribution to Kenji-NX -You can contribute to Ryujinx with PRs, testing of PRs and issues. Contributing code and other implementations is greatly appreciated alongside simply filing issues for problems you encounter. +You can contribute to Kenji-NX with PRs, testing of PRs and issues. Contributing code and other implementations is greatly appreciated alongside simply filing issues for problems you encounter. Please read the entire document before continuing as it can potentially save everyone involved a significant amount of time. # Quick Links @@ -14,17 +14,17 @@ We always welcome bug reports, feature proposals and overall feedback. Here are ### Finding Existing Issues -Before filing a new issue, please search our [open issues](https://github.com/KeatonTheBot/Ryujinx/issues) to check if it already exists. +Before filing a new issue, please search our [open issues](https://git.ryujinx.app/kenji-nx/ryujinx/-/issues) to check if it already exists. If you do find an existing issue, please include your own feedback in the discussion. Do consider upvoting (👍 reaction) the original post, as this helps us prioritize popular issues in our backlog. ### Writing a Good Feature Request -Please review any feature requests already opened to both check it has not already been suggested, and to familiarize yourself with the format. When ready to submit a proposal, please use the [Feature Request issue template](https://github.com/Ryujinx/Ryujinx/issues/new?assignees=&labels=&projects=&template=feature_request.yml&title=%5BFeature+Request%5D). +Please review any feature requests already opened to both check it has not already been suggested, and to familiarize yourself with the format. When ready to submit a proposal, please go [here](https://git.ryujinx.app/kenji-nx/ryujinx/-/issues). ### Writing a Good Bug Report -Good bug reports make it easier for maintainers to verify and root cause the underlying problem. The better a bug report, the faster the problem will be resolved. +Good bug reports make it easier for maintainers to verify and root cause the underlying problem. The better a bug report, the faster the problem will be resolved. Ideally, a bug report should contain the following information: * A high-level description of the problem. @@ -34,13 +34,13 @@ Ideally, a bug report should contain the following information: * A Ryujinx log file of the run instance where the issue occurred. Log files can be found in `[Executable Folder]/Logs` and are named chronologically. * Additional information, e.g. is it a regression from previous versions? Are there any known workarounds? -When ready to submit a bug report, please use the [Bug Report issue template](https://github.com/KeatonTheBot/Ryujinx/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D). +When ready to submit a bug report, please go [here](https://git.ryujinx.app/kenji-nx/ryujinx/-/issues. ## Contributing Changes Project maintainers will merge changes that both improve the project and meet our standards for code quality. -The [Pull Request Guide](docs/workflow/pr-guide.md) and [License](https://github.com/KeatonTheBot/Ryujinx/blob/master/LICENSE.txt) docs define additional guidance. +The [Pull Request Guide](docs/workflow/pr-guide.md) and [License](LICENSE.txt) docs define additional guidance. ### DOs and DON'Ts @@ -67,30 +67,25 @@ Please do not: We use and recommend the following workflow: 1. Create or find an issue for your work. - - You can skip this step for trivial changes. - - Get agreement from the team and the community that your proposed change is a good one if it is of significant size or changes core functionality. - - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. + - You can skip this step for trivial changes. + - Get agreement from the team and the community that your proposed change is a good one if it is of significant size or changes core functionality. + - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. 2. Create a personal fork of the repository on GitHub (if you don't already have one). 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. - - [Build Instructions](https://github.com/KeatonTheBot/Ryujinx#building) explains how to build and test. - - Commit messages should be clear statements of action and intent. + - [Build Instructions](https://git.ryujinx.app/kenji-nx/ryujinx#building) explains how to build and test. + - Commit messages should be clear statements of action and intent. 6. Build the repository with your changes. - - Make sure that the builds are clean. - - Make sure that `dotnet format` has been run and any corrections tested and committed. + - Make sure that the builds are clean. + - Make sure that `dotnet format` has been run and any corrections tested and committed. 7. Create a pull request (PR) against the Ryujinx/Ryujinx repository's **main** branch. - - 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/KeatonTheBot/Ryujinx/actions) to check for outstanding errors. + - State in the description what issue or improvement your change is addressing. 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/ci/pr-guide.md). 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. - - You can delete the branch you used for making the change. - -### Good First Issues - -The team marks the most straightforward issues as [good first issues](https://github.com/KeatonTheBot/Ryujinx/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22). This set of issues is the place to start if you are interested in contributing but new to the codebase. + - The next official build will automatically include your change. + - You can delete the branch you used for making the change. ### Commit Messages @@ -111,15 +106,6 @@ Fix #42 Also do your best to factor commits appropriately, not too large with unrelated things in the same commit, and not too small with the same small change applied N times in N different commits. -### PR - CI Process - -The [Ryujinx continuous integration](https://github.com/KeatonTheBot/Ryujinx/actions) (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean or have bugs properly filed against flaky/unexpected failures that are unrelated to your change. - -If the CI build fails for any reason, the PR actions tab should be consulted for further information on the failure. There are a few usual suspects for such a failure: -* `dotnet format` has not been run on the PR and has outstanding stylistic issues. -* There is an error within the PR that fails a test or errors the compiler. -* Random failure of the workflow can occasionally result in a CI failure. In this scenario a maintainer will manually restart the job. - ### PR Feedback Ryujinx team and community members will provide feedback on your change. Community feedback is highly valued. You may see the absence of team feedback if the community has already provided good review feedback. @@ -134,5 +120,5 @@ Ryujinx uses some implementations and frameworks from other projects. The follow - The license of the file is [permissive](https://en.wikipedia.org/wiki/Permissive_free_software_licence). - The license of the file is left in-tact. -- The contribution is correctly attributed in the [3rd party notices](https://github.com/KeatonTheBot/Ryujinx/blob/master/distribution/legal/THIRDPARTY.md) file in the repository, as needed. +- The contribution is correctly attributed in the [3rd party notices](distribution/legal/THIRDPARTY.md) file in the repository, as needed. diff --git a/README.md b/README.md index 5cf2e337b..06c798cd6 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,11 @@


- Kenji-NX + Kenji-NX
Kenji-NX
- - + Latest Release

@@ -14,7 +14,7 @@ Kenji-NX is an open-source Nintendo Switch emulator, originally created by gdkchan, written in C#. This emulator aims at providing excellent accuracy and performance, a user-friendly interface and consistent builds. It was written from scratch and development on the project began in September 2017. - Kenji-NX is available on GitHub under the MIT license. + Kenji-NX is available on GitHub under the MIT license.

On October 1st 2024, Ryujinx was discontinued as the creator was forced to abandon the project.

@@ -59,11 +59,11 @@ If you wish to build the emulator yourself, follow these steps: ### Step 1 Install the [.NET 9.0 (or higher) SDK](https://dotnet.microsoft.com/download/dotnet/9.0). -Make sure your SDK version is higher or equal to the required version specified in [global.json](global.json). +Make sure your SDK version is higher or equal to the required version specified in [global.json](global.json). ### Step 2 -Either use `git clone https://github.com/KeatonTheBot/Kenji-NX` on the command line to clone the repository or use Code --> Download zip button to get the files. +Either use `git clone https://git.ryujinx.app/kenji-nx/ryujinx` on the command line to clone the repository or use Code --> Download zip button to get the files. ### Step 3 diff --git a/docs/README.md b/docs/README.md index a22da3c7c..82ebb8d2c 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,11 +1,11 @@ # Documents Index -This repo includes several documents that explain both high-level and low-level concepts about Ryujinx and its functions. These are very useful for contributors, to get context that can be very difficult to acquire from just reading code. +This repo includes several documents that explain both high-level and low-level concepts about Kenji-NX and its functions. These are very useful for contributors, to get context that can be very difficult to acquire from just reading code. -Intro to Ryujinx +Intro to Kenji-NX ================== -Ryujinx is an open-source Nintendo Switch emulator, created by gdkchan, written in C#. +Kenji-NX is an open-source Nintendo Switch emulator written in C#. It is based on Ryujinx, which was originally created by gdkchan. * The CPU emulator, ARMeilleure, emulates an ARMv8 CPU and currently has support for most 64-bit ARMv8 and some of the ARMv7 (and older) instructions. * The GPU emulator emulates the Switch's Maxwell GPU using either the OpenGL (version 4.5 minimum), Vulkan, or Metal (via MoltenVK) APIs through a custom build of OpenTK or Silk.NET respectively. * Audio output is entirely supported via C# wrappers for SDL2, with OpenAL & libsoundio as fallbacks. diff --git a/docs/workflow/pr-guide.md b/docs/workflow/pr-guide.md index 82124b91a..304edbbe6 100644 --- a/docs/workflow/pr-guide.md +++ b/docs/workflow/pr-guide.md @@ -2,7 +2,7 @@ ## Contributing Rules -All contributions to KeatonTheBot/Ryujinx repository are made via pull requests (PRs) rather than through direct commits. The pull requests are reviewed and merged by the maintainers after a review and at least two approvals from the core development team. +All contributions to Kenji-NX repository are made via pull requests (PRs) rather than through direct commits. The pull requests are reviewed and merged by the maintainers after a review and at least two approvals from the core development team. To merge pull requests, you must have write permissions in the repository. @@ -18,17 +18,13 @@ To merge pull requests, you must have write permissions in the repository. ## Pull Request Ownership -Every pull request will have automatically have labels and reviewers assigned. The label not only indicates the code segment which the change touches but also the area reviewers to be assigned. +Every pull request will automatically have labels and reviewers assigned. The label not only indicates the code segment which the change touches but also the area reviewers to be assigned. If during the code review process a merge conflict occurs, the PR author is responsible for its resolution. Help will be provided if necessary although GitHub makes this easier by allowing simple conflict resolution using the [conflict-editor](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github). -## Pull Request Builds - -When submitting a PR to the `KeatonTheBot/Ryujinx` repository, various builds will run validating many areas to ensure we keep developer productivity and product quality high. These various workflows can be tracked in the [Actions](https://github.com/KeatonTheBot/Ryujinx/actions) tab of the repository. If the job continues to completion, the build artifacts will be uploaded and posted as a comment in the PR discussion. - ## Review Turnaround Times -Ryujinx is a project that is maintained by volunteers on a completely free-time basis. As such we cannot guarantee any particular timeframe for pull request review and approval. Weeks to months are common for larger (>500 line) PRs but there are some additional best practises to avoid review purgatory. +Kenji-NX is a project that is maintained by volunteers on a completely free-time basis. As such we cannot guarantee any particular timeframe for pull request review and approval. Weeks to months are common for larger (>500 line) PRs but there are some additional best practises to avoid review purgatory. * Make the reviewers life easier wherever possible. Make use of descriptive commit names, code comments and XML docs where applicable. * If there is disagreement on feedback then always lean on the side of the development team and community over any personal opinion. @@ -41,8 +37,7 @@ To re-iterate, make the review as easy for us as possible, respond promptly and Anyone with write access can merge a pull request manually when the following conditions have been met: * The PR has been approved by two reviewers and any other objections are addressed. - * You can request follow up reviews from the original reviewers if they requested changes. -* The PR successfully builds and passes all tests in the Continuous Integration (CI) system. In case of failures, refer to the [Actions](https://github.com/KeatonTheBot/Ryujinx/actions) tab of your PR. + * You can request follow-up reviews from the original reviewers if they requested changes. Typically, PRs are merged as one commit (squash merges). It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to dissect them.