mirror of
https://codeberg.org/anoncontributorxmr/monero.git
synced 2024-11-25 00:42:27 +00:00
Change "Github" to "GitHub"
This commit is contained in:
parent
67e5ca9ad6
commit
070e41d88b
5 changed files with 7 additions and 7 deletions
|
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
|
@ -738,7 +738,7 @@ For more detailed information see the ['Pruning' entry in the Moneropedia](https
|
|||
|
||||
## 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
|
||||
|
||||
|
|
|
@ -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
|
||||
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.
|
||||
|
||||
|
|
|
@ -136,7 +136,7 @@ GH_USER=YOUR_GITHUB_USER_NAME
|
|||
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:
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ of software solid and usable.
|
|||
* 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.
|
||||
|
||||
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
|
||||
(eg, posted to fpaste.org with a long enough timeout and a link
|
||||
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,
|
||||
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
|
||||
your submitted branch, please. You may be asked to rebase if there
|
||||
are conflicts (even trivially resolvable ones).
|
||||
|
|
|
@ -134,7 +134,7 @@ namespace zmq
|
|||
{
|
||||
/* ZMQ documentation states that message parts are atomic - either
|
||||
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
|
||||
verify (for the `inproc://` case) that this is the behavior.
|
||||
Therefore, read errors after the first part are treated as a
|
||||
|
|
Loading…
Reference in a new issue