Added section to Contributing.md detailing our desired pre-release code auditing process #1848
Conversation
| At the moment, we're looking for a tool that lets us statically figure out every message that had something in its code path that changed. Until a tool is found, we must do this manually. | ||
|
|
||
| We test in testnet & e2e testnet behaviors about every message that has changed |
There was a problem hiding this comment.
test in e2e testnet about every message that has changed
I'm all for trying it but are we actually going to test every changed message in e2e before a major release? Is this an achievable commitment in practice?
There was a problem hiding this comment.
cc @ValarDragon for thoughts?
There was a problem hiding this comment.
Personally I think this requires an extra step of testing but I'm not sure on what your thoughts are on the potential significance of overhead in patches where lots of messages are added (rather, how often these happen). If it's not too significant then it may be do-able.
There was a problem hiding this comment.
Please don't feel the need to block the PR on this comment if that's what's happening. I'm just reading between the lines.
I think that the commitment to manually test every changed message on testnet is a must. My concern is only with respect to e2e. Please consider not mentioning it here.
At the moment, we don't have the capacity to test every changed message on the e2e testnet. So the commitment might not be realistic. We should be slowly moving towards that over time so that we can minimize manual testnet testing.
There was a problem hiding this comment.
I think this is fine to list for now - We need to make capacity for testing changed messages on testnet & work towards mitigating # of changes per release / making smaller releases more reasonable imo
Co-authored-by: Roman <[email protected]>
CONTRIBUTING.md
Outdated
| Make sure to also do `make all` to run all the linting tests before you commit and push, as well as `gofmt`-ing the file you've modified or added to make sure everything still abides by the standards. |
There was a problem hiding this comment.
This line should be deleted, as its not part of making proto files. (Also not how I'd suggest getting this integration to folks personally)
At most run make format, but really just set up your IDE to do it for you on-save
There was a problem hiding this comment.
Adding resources to help people setup their IDE for autosave (and rec to run make format)
|
TY for adding this! |
Closes: #1830
What is the purpose of the change
This PR adds a section to the contributing.md labeled "Major release" detailing our desired pre-release code auditing and actual release workflow processes.
Brief Changelog
Added a section to the contributing.md labeled "Major release" detailing:
The actual release workflow
The pre-release internal auditing process we've discussed as per notes on #1830
Testing and Verifying
(Please pick one of the following options)
This change is a trivial rework / code cleanup without any test coverage.
Documentation and Release Note
Unreleasedsection inCHANGELOG.md? (yes / no)x/<module>/spec/) / [Osmosis docs repo](https://github.com/osmosis-labs/docs) / not documented)This change will be synced up with a future PR that creates an action syncing contributing.md docs on the docs repo with this one.