rottenwheel/monero
1
0
Fork 0
mirror of https://codeberg.org/anoncontributorxmr/monero.git synced 2024-11-22 07:22:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Change "Github" to "GitHub"

Browse source
This commit is contained in:
Abdullah 2022-04-27 18:53:03 +01:00
parent 67e5ca9ad6
commit 070e41d88b
5 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
README.md
View file

@ -81,7 +81,7 @@ Monero is a private, secure, untraceable, decentralised digital currency. You ar
This is the core implementation of Monero. It is open source and completely free to use without restrictions, except for those specified in the license agreement below. There are no restrictions on anyone creating an alternative implementation of Monero that uses the protocol and network in a compatible manner. This is the core implementation of Monero. It is open source and completely free to use without restrictions, except for those specified in the license agreement below. There are no restrictions on anyone creating an alternative implementation of Monero that uses the protocol and network in a compatible manner.
As with many development projects, the repository on Github is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability. As with many development projects, the repository on GitHub is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability.
**Anyone is welcome to contribute to Monero's codebase!** If you have a fix or code change, feel free to submit it as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase, it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request. **Anyone is welcome to contribute to Monero's codebase!** If you have a fix or code change, feel free to submit it as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase, it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request.
@ -738,7 +738,7 @@ For more detailed information see the ['Pruning' entry in the Moneropedia](https
## Debugging ## Debugging
This section contains general instructions for debugging failed installs or problems encountered with Monero. First, ensure you are running the latest version built from the Github repo. This section contains general instructions for debugging failed installs or problems encountered with Monero. First, ensure you are running the latest version built from the GitHub repo.
### Obtaining stack traces and core dumps on Unix systems ### Obtaining stack traces and core dumps on Unix systems

2
contrib/gitian/DOCKRUN.md
View file

@ -70,7 +70,7 @@ The build should run to completion with no errors, and will display the SHA256 c
of the resulting binaries. You'll be prompted to check if the sums look good, and if so of the resulting binaries. You'll be prompted to check if the sums look good, and if so
then the results will be signed, and the signatures will be pushed to GitHub. then the results will be signed, and the signatures will be pushed to GitHub.
***Note: In order to publish the signed assertions via this script, you need to have your SSH key uploaded to Github beforehand. See https://docs.github.com/articles/generating-an-ssh-key/ for more info.*** ***Note: In order to publish the signed assertions via this script, you need to have your SSH key uploaded to GitHub beforehand. See https://docs.github.com/articles/generating-an-ssh-key/ for more info.***
You can also look in the [gitian.sigs](https://github.com/monero-project/gitian.sigs/) repo and / or [getmonero.org release checksums](https://web.getmonero.org/downloads/hashes.txt) to see if others got the same checksum for the same version tag. If there is ever a mismatch -- **STOP! Something is wrong**. Contact others on IRC / GitHub to figure out what is going on. You can also look in the [gitian.sigs](https://github.com/monero-project/gitian.sigs/) repo and / or [getmonero.org release checksums](https://web.getmonero.org/downloads/hashes.txt) to see if others got the same checksum for the same version tag. If there is ever a mismatch -- **STOP! Something is wrong**. Contact others on IRC / GitHub to figure out what is going on.

2
contrib/gitian/README.md
View file

@ -136,7 +136,7 @@ GH_USER=YOUR_GITHUB_USER_NAME
VERSION=v0.17.2.0 VERSION=v0.17.2.0
``` ```
Where `GH_USER` is your Github user name and `VERSION` is the version tag you want to build. Where `GH_USER` is your GitHub user name and `VERSION` is the version tag you want to build.
Setup for LXC: Setup for LXC:

4
docs/CONTRIBUTING.md
View file

@ -12,7 +12,7 @@ of software solid and usable.
* If modifying code for which Doxygen headers exist, that header must be modified to match. * If modifying code for which Doxygen headers exist, that header must be modified to match.
* Tests would be nice to have if you're adding functionality. * Tests would be nice to have if you're adding functionality.
Patches are preferably to be sent via a Github pull request. If that Patches are preferably to be sent via a GitHub pull request. If that
can't be done, patches in "git format-patch" format can be sent can't be done, patches in "git format-patch" format can be sent
(eg, posted to fpaste.org with a long enough timeout and a link (eg, posted to fpaste.org with a long enough timeout and a link
posted to #monero-dev on irc.libera.chat). posted to #monero-dev on irc.libera.chat).
@ -43,7 +43,7 @@ Commit messages should be sensible. That means a subject line that
describes the patch, with an optional longer body that gives details, describes the patch, with an optional longer body that gives details,
documentation, etc. documentation, etc.
When submitting a pull request on Github, make sure your branch is When submitting a pull request on GitHub, make sure your branch is
rebased. No merge commits nor stray commits from other people in rebased. No merge commits nor stray commits from other people in
your submitted branch, please. You may be asked to rebase if there your submitted branch, please. You may be asked to rebase if there
are conflicts (even trivially resolvable ones). are conflicts (even trivially resolvable ones).

2
src/net/zmq.cpp
View file

@ -134,7 +134,7 @@ namespace zmq
{ {
/* ZMQ documentation states that message parts are atomic - either /* ZMQ documentation states that message parts are atomic - either
all are received or none are. Looking through ZMQ code and all are received or none are. Looking through ZMQ code and
Github discussions indicates that after part 1 is returned, GitHub discussions indicates that after part 1 is returned,
`EAGAIN` cannot be returned to meet these guarantees. Unit tests `EAGAIN` cannot be returned to meet these guarantees. Unit tests
verify (for the `inproc://` case) that this is the behavior. verify (for the `inproc://` case) that this is the behavior.
Therefore, read errors after the first part are treated as a Therefore, read errors after the first part are treated as a