LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore: clean repo (#24723)

Browse Source
This commit is contained in:
Alex | Interchain Labs
2025-05-08 15:44:28 -04:00
committed by GitHub
parent 5d28bf5540
commit acb3d74760
18 changed files with 0 additions and 1605 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/ISSUE_TEMPLATE/bug-report.md
-30
View File
@@ -1,30 +0,0 @@
---
name: Bug Report
about: Create a report to help us squash bugs!
title: "[Bug]: "
labels: "T:Bug"
---
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Please also ensure that this is not a duplicate issue :)
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
<!--
IMPORTANT: Prior to opening a bug report, check if it affects one of the core modules
and if its elegible for a bug bounty on `SECURITY.md`. Bugs that are not submitted
through the appropriate channels won't receive any bounty.
-->
## Summary of Bug
<!-- Concisely describe the issue -->
## Version
<!-- git commit hash or release version -->
## Steps to Reproduce
<!-- What commands in order should someone run to reproduce your problem? -->
.github/ISSUE_TEMPLATE/bug-report.yml
-49
View File
@@ -1,49 +0,0 @@
name: 🐛 Bug report
description: Create a report to help us squash bugs!
title: "[Bug]: "
labels: ["T:Bug"]
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this bug report!
Before smashing the submit button please review the template.
- type: checkboxes
attributes:
label: Is there an existing issue for this?
description: Please search existing issues to avoid creating duplicates.
options:
- label: I have searched the existing issues
required: true
- type: markdown
attributes:
value: |
IMPORTANT: Prior to opening a bug report, check if it affects one of the core modules
and if its eligible for a bug bounty on `SECURITY.md`. Bugs that are not submitted
through the appropriate channels won't receive any bounty.
- type: textarea
id: what-happened
attributes:
label: What happened?
description: Also tell us, what did you expect to happen?
placeholder: Tell us what you see!
value: "A bug happened!"
validations:
required: true
- type: input
attributes:
label: Cosmos SDK Version
description: If applicable, specify the version you're using
placeholder: 0.46, 0.47, main, etc.
validations:
required: true
- type: textarea
id: reproduce
attributes:
label: How to reproduce?
description: If applicable could you describe how we could reproduce the bug
placeholder: Tell us what how to reproduce the bug!
validations:
required: false
.github/ISSUE_TEMPLATE/documentation.yml
-18
View File
@@ -1,18 +0,0 @@
name: Documentation Request
description: Create an issue for missing or incorrect documentation
title: "[Documentation]: "
labels: ["T:Docs"]
body:
- type: markdown
attributes:
value: |
✰ Thanks for opening an issue! ✰
Tell us where what you would like to see get added to the documentation or if there is an error in the documentation?
- type: textarea
id: what-happened
attributes:
label: Summary
placeholder: Description of what you would like to see
validations:
required: true
.github/ISSUE_TEMPLATE/epics.md
-31
View File
@@ -1,31 +0,0 @@
---
name: Epic
about: Create an epic/user
title: "[Epic]: "
labels: T:Epic
---
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
## Summary
<!-- Short, concise description of the proposed feature/changes to the repository
What are the user needs?
How could this solution fix the user facing problem? -->
## Problem Definition
<!-- Why do we need this feature?
What problems may be addressed by introducing this feature?
What benefits does the SDK stand to gain by including this feature?
Are there any disadvantages of including this feature? -->
## Work Breakdown
<!-- Break the work into many bullet points that will later be turned into issues that can be assigned to developers to work on
This work may been to be broken up into phases of work in order to better organize when and how things get done. -->
.github/ISSUE_TEMPLATE/epics.yml
-43
View File
@@ -1,43 +0,0 @@
name: Epic
description: Create an epic/user
title: "[Epic]: "
labels: ["T:Epic"]
body:
- type: markdown
attributes:
value: |
Thanks for opening this issue, this template is meant for long lived work scopes, if this is what you're looking for please continue
- type: textarea
id: summary
attributes:
label: Summary
description: |
What are the user needs?
How could this solution fix the user facing problem?
placeholder: Short, concise description of the proposed feature/changes to the repository
validations:
required: true
- type: textarea
id: problem
attributes:
label: Problem Definition
description: |
Why do we need this feature?
What problems may be addressed by introducing this feature?
What benefits does the SDK stand to gain by including this feature?
Are there any disadvantages of including this feature?
placeholder: Description of the issue being faced
validations:
required: true
- type: textarea
id: work
attributes:
label: Work Breakdown
description: |
Break the work into many bullet points that will later be turned into issues that can be assigned to developers to work on
This work may been to be broken up into phases of work in order to better organize when and how things get done.
placeholder: Description of the steps needed to deliver this feature
validations:
required: true
.github/ISSUE_TEMPLATE/feature-request.md
-28
View File
@@ -1,28 +0,0 @@
---
name: Feature Request
about: Create a proposal to request a feature
title: "[Feature]: "
labels: T:feature-request
---
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
## Summary
<!-- Short, concise description of the proposed feature -->
## Problem Definition
<!-- Why do we need this feature?
What problems may be addressed by introducing this feature?
What benefits does the SDK stand to gain by including this feature?
Are there any disadvantages of including this feature? -->
## Proposal
<!-- Detailed description of requirements of implementation -->
.github/ISSUE_TEMPLATE/feature-request.yml
-41
View File
@@ -1,41 +0,0 @@
name: Feature Request
description: Create a proposal to request a feature
title: "[Feature]: "
labels: ["T:feature-request"]
body:
- type: markdown
attributes:
value: |
✰ Thanks for opening an issue! ✰
- type: textarea
id: summary
attributes:
label: Summary
description: |
What are the user needs?
How could this solution fix the user facing problem?
placeholder: Short, concise description of the proposed feature/changes to the repository
validations:
required: true
- type: textarea
id: problem
attributes:
label: Problem Definition
description: |
If applicable please answer the below questions
Why do we need this feature?
What problems may be addressed by introducing this feature?
What benefits does the SDK stand to gain by including this feature?
Are there any disadvantages of including this feature?
placeholder: Description of the issue being faced
validations:
required: false
- type: textarea
id: proposal
attributes:
label: Proposed Feature
description: |
Description of the proposed features or changes to an existing feature to meet your needs
placeholder: Description of the proposed feature(s)
validations:
required: true
.github/ISSUE_TEMPLATE/module-readiness-checklist.md
-40
View File
@@ -1,40 +0,0 @@
---
name: Module Readiness Checklist
about: Pre-flight checklist that modules must pass in order to be included in a release of the Cosmos SDK
labels: 'module-readiness-checklist'
---
## x/{MODULE_NAME} Module Readiness Checklist
This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release.
### Release Candidate Checklist
The following checklist should be gone through once the module has been fully implemented. This audit should be performed directly on `main`, or preferably on a `alpha` or `beta` release tag that includes the module.
The module **should not** be included in any Release Candidate tag until it has passed this checklist.
- [ ] API audit (at least 1 person) (@assignee)
- [ ] Are Msg and Query methods and types well-named and organized?
- [ ] Is everything well documented (inline godoc as well as the spec [README.md](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/README.md) in module directory)
- [ ] State machine audit (at least 2 people) (@assignee1, @assignee2)
- [ ] Read through MsgServer code and verify correctness upon visual inspection
- [ ] Ensure all state machine code which could be confusing is properly commented
- [ ] Make sure state machine logic matches Msg method documentation
- [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code)
- [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method
- [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
- [ ] Completeness audit, fully implemented with tests (at least 1 person) (@assignee)
- [ ] Genesis import and export of all state
- [ ] Query services
- [ ] CLI methods
- [ ] All necessary migration scripts are present (if this is an upgrade of existing module)
### Published Release Checklist
After the above checks have been audited and the module is included in a tagged Release Candidate, the following additional checklist should be undertaken for live testing, and potentially a 3rd party audit (if deemed necessary):
- [ ] Testnet / devnet testing (2-3 people) (@assignee1, @assignee2, @assignee3)
- [ ] All Msg methods have been tested especially in light of any potential threats identified
- [ ] Genesis import and export has been tested
- [ ] Nice to have (and needed in some cases if threats could be high): Official 3rd party audit
.github/ISSUE_TEMPLATE/qa.md
-87
View File
@@ -1,87 +0,0 @@
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
## Summary
<!-- In a few short sentences summarize the release -->
## Major Changes
<!-- Describe the major changes associated to this release -->
## Gotchas
<!-- Gotchas is an area which changes could of been made that the auditors should be aware of -->
## QA Breakdown
* Audit
* [ ] Audit BaseApp
* [ ] Audit Types
* [ ] Audit x/auth
* [ ] Audit x/authz
* [ ] Audit x/bank
* [ ] Audit x/circuit
* [ ] Audit x/consensus
* [ ] Audit x/distribution
* [ ] Audit x/evidence
* [ ] Audit x/epochs
* [ ] Audit x/feegrant
* [ ] Audit x/genutil
* [ ] Audit x/gov
* [ ] Audit x/group
* [ ] Audit x/mint
* [ ] Audit x/nft
* [ ] Audit x/protocolpool
* [ ] Audit x/slashing
* [ ] Audit x/staking
* [ ] Audit x/tx
* [ ] Audit x/upgrade
* [ ] Audit client
* [ ] Audit server
* [ ] Audit store
* [ ] Audit runtime
* [ ] Audit simapp
* [ ] Release alpha
* [ ] Cosmos-SDK testnet
* [ ] Public testnet (IBC, WASM, SDK)
* [ ] Upgrade a chain with data from vX
* Release documentation
* [ ] Audit UPGRADING.md
* [ ] Update all codeblock to the appropriate version number
### Audit checklist
* please copy to a markdown to follow while you walk through the code
* 2 people should be assigned to each section
* [ ] API audit
* spec audit: check if the spec is complete.
* Are Msg and Query methods and types well-named and organized?
* Is everything well documented (inline godoc as well as package [`README.md`](https://docs.cosmos.network/main/spec/SPEC_MODULE#common-layout) in module directory)
* check the proto definition - make sure everything is in accordance to ADR-30 (at least 1 person, TODO assignee)
* Check new fields and endpoints have the `Since: cosmos-sdk X` comment
* [ ] Completeness audit, fully implemented with tests
* [ ] Genesis import and export of all state
* [ ] Query services
* [ ] CLI methods
* [ ] All necessary migration scripts are present (if this is an upgrade of existing module)
* [ ] State machine audit
* [ ] Read through MsgServer code and verify correctness upon visual inspection
* [ ] Ensure all state machine code which could be confusing is properly commented
* [ ] Make sure state machine logic matches Msg method documentation
* [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code)
* [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method. Specifically we should be paying attention to:
* [ ] algorithmic complexity and places this could be exploited (ex. nested `for` loops)
* [ ] charging gas complex computation (ex. `for` loops)
* [ ] storage is safe (we don't pollute the state).
* [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
* [ ] Check correctness of simulation implementation if any
* [ ] Audit Changelog against commit log, ensuring all breaking changes, bug fixes, and improvements are properly documented.
If any changes are needed, please make them against main and backport them to release/vX.X.x
.github/PULL_REQUEST_TEMPLATE.md
-32
View File
@@ -4,35 +4,3 @@ Closes: #XXXX
<!-- Add a description of the changes that this PR introduces and the files that
are the most critical to review. -->
---
## Author Checklist
*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues. Your PR will not be merged unless you satisfy
all of these items.*
I have...
* [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title, you can find examples of the prefixes below:
<!-- * `feat`: A new feature
* `fix`: A bug fix
* `docs`: Documentation only changes
* `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* `refactor`: A code change that neither fixes a bug nor adds a feature
* `perf`: A code change that improves performance
* `test`: Adding missing tests or correcting existing tests
* `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* `chore`: Other changes that don't modify src or test files
* `revert`: Reverts a previous commit -->
* [ ] confirmed `!` in the type prefix if API or client breaking change
* [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting))
* [ ] provided a link to the relevant issue or specification
* [ ] reviewed "Files changed" and left comments if necessary
* [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing)
* [ ] added a changelog entry to `CHANGELOG.md`
* [ ] updated the relevant documentation or specification, including comments for [documenting Go code](https://blog.golang.org/godoc)
* [ ] confirmed all CI checks have passed