From 0767b5a3fb89aeacb124fc6f64c0efc7b6bcc0df Mon Sep 17 00:00:00 2001 From: Samuel Oronti <135102798+samdotola@users.noreply.github.com> Date: Sun, 5 Jan 2025 02:54:17 +0100 Subject: [PATCH 1/6] Update SECURITY.md typo corrections --- SECURITY.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index f778f34c6db19f..3a721aefdd9833 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -26,7 +26,7 @@ Expect a response as fast as possible in the advisory, typically within 72 hours If you do not receive a response in the advisory, send an email to security@solana.com with the full URL of the advisory you have created. DO NOT -include attachments or provide detail sufficient for exploitation regarding the +include attachments or provide details sufficient for exploitation regarding the security issue in this email. **Only provide such details in the advisory**. If you do not receive a response from security@solana.com please followup with @@ -38,10 +38,10 @@ role in the channel and referencing the fact that you submitted a security probl ## Incident Response Process In case an incident is discovered or reported, the following process will be -followed to contain, respond and remediate: +followed to contain, respond, and remediate: ### 1. Accept the new report -In response a newly reported security problem, a member of the +In response to a newly reported security problem, a member of the `anza-xyz/admins` group will accept the report to turn it into a draft advisory. The `anza-xyz/security-incident-response` group should be added to the draft security advisory, and create a private fork of the repository (grey @@ -57,7 +57,7 @@ Within the draft security advisory, discuss and determine the severity of the is If it is determined that this is not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created. ### 3. Prepare Fixes -For the affected branches, typically all three (edge, beta and stable), prepare a fix for the issue and push them to the corresponding branch in the private repository associated with the draft security advisory. +For the affected branches, typically all three (edge, beta, and stable), prepare a fix for the issue and push it to the corresponding branch in the private repository associated with the draft security advisory. There is no CI available in the private repository so you must build from source and manually verify fixes. Code review from the reporter is ideal, as well as from multiple members of the core development team. From 123739ef983f8548d85e2e70408578b0cff23c84 Mon Sep 17 00:00:00 2001 From: Samuel Oronti <135102798+samdotola@users.noreply.github.com> Date: Sun, 5 Jan 2025 03:07:15 +0100 Subject: [PATCH 2/6] Update RELEASE.md typo error --- RELEASE.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index a862a0e4106ceb..16fac2851ca065 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -81,7 +81,7 @@ for at least one full minor version before removal. git push -u origin ``` -Alternatively use the Github UI. +Alternatively, use the Github UI. ### Update master branch to the next release minor version @@ -101,7 +101,7 @@ Alternatively use the Github UI. ci/channel-info.sh ``` -### Miscellaneous Clean up +### Miscellaneous Clean-up 1. Pin the spl-token-cli version in the newly promoted stable branch by setting `splTokenCliVersion` in scripts/spl-token-cli-version.sh to the latest release that depends on the stable branch (usually this will be the latest spl-token-cli release). 1. Update [mergify.yml](https://github.com/anza-xyz/agave/blob/master/.mergify.yml) to add backport actions for the new branch and remove actions for the obsolete branch. @@ -126,10 +126,10 @@ Alternatively use the Github UI. 1. Ensure all desired commits (usually backports) are landed on the branch by now. 1. Ensure the release is marked **"This is a pre-release"**. This flag will need to be removed manually after confirming the Linux binary artifacts appear at a later step. 1. Go back into edit the release and click "Publish release" while being marked as a pre-release. -1. Confirm there is new git tag with intended version number at the intended revision after running `git fetch` locally. +1. Confirm there is a new git tag with the intended version number at the intended revision after running `git fetch` locally. -### Update release branch with the next patch version +### Update the release branch with the next patch version [This action](https://github.com/anza-xyz/agave/blob/master/.github/workflows/increment-cargo-version-on-release.yml) ensures that publishing a release will trigger the creation of a PR to update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1). Ensure that the created PR makes it through CI and gets submitted. @@ -148,7 +148,7 @@ appearing. To check for progress: * The `agave-secondary` Buildkite pipeline handles creating the Linux and macOS release artifacts and updated crates. Look for a job under the tag name of the release: https://buildkite.com/anza-xyz/agave-secondary. * The Windows release artifacts are produced by GitHub Actions. Look for a job under the tag name of the release: https://github.com/anza-xyz/agave/actions. -[Crates.io agave-validator](https://crates.io/crates/agave-validator) should have an updated agave-validator version. This can take 2-3 hours, and sometimes fails in the `agave-secondary` job. +[Crates.io agave-validator](https://crates.io/crates/agave-validator) should have an updated agave-validator version. This can take 2-3 hours and sometimes fails in the `agave-secondary` job. If this happens and the error is non-fatal, click "Retry" on the "publish crate" job ### Update software on testnet.solana.com From 795c1e4147b02808366f1b98d7112388dd394532 Mon Sep 17 00:00:00 2001 From: Samuel Oronti <135102798+samdotola@users.noreply.github.com> Date: Sun, 5 Jan 2025 03:09:54 +0100 Subject: [PATCH 3/6] Update README.md typo error --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 0d855e8cc85c07..ba2d152c973033 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ # Building -## **1. Install rustc, cargo and rustfmt.** +## **1. Install rustc, cargo, and rustfmt.** ```bash $ curl https://sh.rustup.rs -sSf | sh @@ -31,7 +31,7 @@ $ rustup install VERSION ``` Note that if this is not the latest rust version on your machine, cargo commands may require an [override](https://rust-lang.github.io/rustup/overrides.html) in order to use the correct version. -On Linux systems you may need to install libssl-dev, pkg-config, zlib1g-dev, protobuf etc. +On Linux systems, you may need to install libssl-dev, pkg-config, zlib1g-dev, protobuf, etc. On Ubuntu: ```bash @@ -107,7 +107,7 @@ productivity metric. When a developer makes a change to the codebase, presumably some problem. Our unit-test suite is how we encode the set of *problems* the codebase solves. Running the test suite should indicate that your change didn't *infringe* on anyone else's solutions. Adding a test *protects* your solution from future changes. Say you don't understand why a line of code exists, -try deleting it and running the unit-tests. The nearest test failure should tell you what problem +try deleting it and running the unit tests. The nearest test failure should tell you what problem was solved by that code. If no test fails, go ahead and submit a Pull Request that asks, "what problem is solved by this code?" On the other hand, if a test does fail and you can think of a better way to solve the same problem, a Pull Request with your solution would most certainly be From 821b3541fa6f8ac2505e0cfd46023e5341ac45bb Mon Sep 17 00:00:00 2001 From: Samuel Oronti <135102798+samdotola@users.noreply.github.com> Date: Sun, 5 Jan 2025 03:19:37 +0100 Subject: [PATCH 4/6] Update CONTRIBUTING.md typo error --- CONTRIBUTING.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b1595715acc44c..adfd1e233a3c09 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,7 +4,7 @@ The goal of these guidelines is to improve developer productivity by allowing developers to jump into any file in the codebase and not need to adapt to inconsistencies in how the code is written. The codebase should appear as if it had been authored by a single developer. If you don't agree with a convention, -submit a PR patching this document and let's discuss! Once the PR is accepted, +submit a PR patching this document, and let's discuss! Once the PR is accepted, *all* code should be updated as soon as possible to reflect the new conventions. @@ -45,7 +45,7 @@ $ git pull --rebase upstream master If there are no functional changes, PRs can be very large and that's no problem. If, however, your changes are making meaningful changes or additions, -then about 1,000 lines of changes is about the most you should ask a Solana +then about 1,000 lines of changes are about the most you should ask a Solana maintainer to review. ### Should I send small PRs as I develop large, new components? @@ -59,7 +59,7 @@ may be pulled in with a package manager. ## Getting Pull Requests Merged There is no single person assigned to watching GitHub PR queue and ushering you -through the process. Typically, you will ask the person that wrote a component +through the process. Typically, you will ask the person who wrote a component to review changes to it. You can find the author using `git blame` or asking on Discord. When working to get your PR merged, it's most important to understand that changing the code is your priority and not necessarily a priority of the @@ -74,7 +74,7 @@ minutes to execute. Use that time to write a detailed problem description. Once the description is written and CI succeeds, click the "Ready to Review" button and add reviewers. Adding reviewers before CI succeeds is a fast path to losing reviewer engagement. Not only will they be notified and see the PR is not yet -ready for them, they will also be bombarded with additional notifications +ready for them, but they will also be bombarded with additional notifications each time you push a commit to get past CI or until they "mute" the PR. Once muted, you'll need to reach out over some other medium, such as Discord, to request they have another look. When you use draft PRs, no notifications are @@ -99,7 +99,7 @@ more important than competing issues, don't expect the reviewer to read on. Next, the reviewer will read the proposed changes. At this point, the reviewer needs to be convinced the proposed changes are a *good* solution to the problem -described above. If the proposed changes, not the code changes, generates +described above. If the proposed changes, not the code changes, generate discussion, consider closing the PR and returning with a design proposal instead. @@ -148,7 +148,7 @@ matches the logical flow in your PR description. ### The PR / Issue Labels -Labels make it easier to manage and track PRs / issues. Below some common labels +Labels make it easier to manage and track PRs / issues. Below are some common labels that we use in Solana. For the complete list of labels, please refer to the [label page](https://github.com/solana-labs/solana/issues/labels): @@ -158,11 +158,11 @@ New feature gates should also always have a corresponding tracking issue (go to "New Issue" -> "Feature Gate Tracker [Get Started](https://github.com/solana-labs/solana/issues/new?assignees=&labels=feature-gate&template=1-feature-gate.yml&title=Feature+Gate%3A+)") and should be updated each time the feature is activated on a cluster. -* "automerge": When a PR is labelled with "automerge", the PR will be +* "auto-merge": When a PR is labeled with "auto-merge", the PR will be automatically merged once CI passes. In general, this label should only -be used for small hot-fix (fewer than 100 lines) or automatic generated +be used for small hot-fix (fewer than 100 lines) or automatically generated PRs. If you're uncertain, it's usually the case that the PR is not -qualified as "automerge". +qualified as "auto-merge". * "good first issue": If you happen to find an issue that is non-urgent and self-contained with moderate scope, you might want to consider attaching @@ -180,7 +180,7 @@ closed automatically 7 days later. ### How to manage review feedback? After a reviewer provides feedback, you can quickly say "acknowledged, will -fix" using a thumb's up emoji. If you're confident your fix is exactly as +fix" using a thumb 's-up emoji. If you're confident your fix is exactly as prescribed, add a reply "Fixed in COMMIT\_HASH" and mark the comment as resolved. If you're not sure, reply "Is this what you had in mind? COMMIT\_HASH" and if so, the reviewer will reply and mark the conversation as @@ -203,7 +203,7 @@ your PR easy to say "yes" to. Non-exhaustive list of things that make it *harder* to review: * Additional changes that are orthogonal to the problem statement and proposed - changes. Instead move those changes to a different PR. + changes. Instead, move those changes to a different PR. * Renaming variables/functions/types unnecessarily and/or without explanation. * Not following established conventions in the function/module/crate/repo. * Changing whitespace: moving code and/or reformatting code. Make such changes @@ -282,7 +282,7 @@ edition = "2021" installed, it will be updated automatically when you update the compiler with `rustup`. -* All Rust code is linted with Clippy. If you'd prefer to ignore its advice, do +* All Rust code is linked with Clippy. If you'd prefer to ignore its advice, do so explicitly: ```rust @@ -299,7 +299,7 @@ has multiple instances of the same type, qualify each with a prefix and underscore (i.e. alice\_keypair) or a numeric suffix (i.e. tx0). * For function and method names, use `_`. For unit tests, that - verb should always be `test` and for benchmarks the verb should always be + verb should always be `test` and for benchmarks, the verb should always be `bench`. Avoid namespacing function names with some arbitrary word. Avoid abbreviating words in function names. From fd42014e6cd3bc98f82885548a8e08b2ce01030f Mon Sep 17 00:00:00 2001 From: Samuel Oronti <135102798+samdotola@users.noreply.github.com> Date: Sun, 5 Jan 2025 03:24:41 +0100 Subject: [PATCH 5/6] Update CHANGELOG.md typo error --- CHANGELOG.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 0cd6e2b22698d0..5174ed8d64cb79 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -22,7 +22,7 @@ Release channels have their own copy of this changelog: * removed the unreleased `redelegate` instruction processor and CLI commands (#2213) * Changes * SDK: removed the `respan` macro. This was marked as "internal use only" and was no longer used internally. - * `agave-validator`: Update PoH speed check to compare against current hash rate from a Bank (#2447) + * `agave-validator`: Update PoH speed check to compare against the current hash rate from a Bank (#2447) * `solana-test-validator`: Add `--clone-feature-set` flag to mimic features from a target cluster (#2480) ## [2.0.0] @@ -47,7 +47,7 @@ Release channels have their own copy of this changelog: * `--incremental-snapshots` (#2148) * `--halt-on-known-validators-accounts-hash-mismatch` (#2157) * Changes - * `central-scheduler` as default option for `--block-production-method` (#34891) + * `central-scheduler` as the default option for `--block-production-method` (#34891) * `solana-rpc-client-api`: `RpcFilterError` depends on `base64` version 0.22, so users may need to upgrade to `base64` version 0.22 * Changed default value for `--health-check-slot-distance` from 150 to 128 * CLI: Can specify `--with-compute-unit-price`, `--max-sign-attempts`, and `--use-rpc` during program deployment @@ -57,8 +57,8 @@ Release channels have their own copy of this changelog: * CLI: Can specify `--full-snapshot-archive-path` (#1631) * transaction-status: The SPL Token `amountToUiAmount` instruction parses the amount into a string instead of a number (#1737) * Implemented partitioned epoch rewards as per [SIMD-0118](https://github.com/solana-foundation/solana-improvement-documents/blob/fae25d5a950f43bd787f1f5d75897ef1fdd425a7/proposals/0118-partitioned-epoch-reward-distribution.md). Feature gate: #426. Specific changes include: - * EpochRewards sysvar expanded and made persistent (#428, #572) - * Stake Program credits now allowed during distribution (#631) + * EpochRewards sys var expanded and made persistent (#428, #572) + * Stake Program credits are now allowed during distribution (#631) * Updated type in Bank::epoch_rewards_status (#1277) * Partitions are recalculated on boot from snapshot (#1159) * `epoch_rewards_status` removed from snapshot (#1274) @@ -126,13 +126,13 @@ makes the feature code complete. * dapp or client developers to make changes. * Link to any relevant feature gate issues or SIMDs. * If you add entries on multiple branches use the same wording if possible. -This simplifies the process of diffing between versions of the log. +This simplifies the process of differentiating between versions of the log. ## Maintaining This Changelog ### When creating a new release branch: * Commit to master updating the changelog: * Update the edge, beta, and stable links - * Create new section: `vx.y+1.0 - Unreleased` + * Create a new section: `vx.y+1.0 - Unreleased` * Remove `Unreleased` annotation from vx.y.0 section. * Create vx.y branch starting at that commit * Tag that commit as vx.y.0 From c1edd55c58e8431e2cbb610e1951e3462e3efc96 Mon Sep 17 00:00:00 2001 From: Samuel Oronti <135102798+samdotola@users.noreply.github.com> Date: Sun, 5 Jan 2025 03:27:43 +0100 Subject: [PATCH 6/6] Update proposals.md typo --- docs/src/proposals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/proposals.md b/docs/src/proposals.md index 0835a338524a3b..3876ec6eb62f51 100644 --- a/docs/src/proposals.md +++ b/docs/src/proposals.md @@ -20,7 +20,7 @@ Each proposal may be implemented as described, implemented differently as issues These architectural proposals have been accepted and implemented by the Solana team. -Any designs that may be subject to future change are noted in their specific proposal page. +Any designs that may be subject to future change are noted on their specific proposal page. ## Submit a Design Proposal