Strangelove as IBC Repository Maintainer Coordinator

Hey so I just wanted to add a little detail to this, here is where I first discussed this concept:

I think that it is very important that:

Repositories be grouped by function like:

  • No one uses IAVL, ledger-cosmos-go, and cosmos-db without the SDK, therefore put all of them in the SDK

  • No one uses cometbft-db without cometbft, therefore put cometbft-db in cometbft

  • The vast majority of IBC enabled chains built using the cosmos SDK will want packet forward middleware, ICQ, and WASM clients, therefore those tools should go directly into the IBC go repository

Benefits of this approach

  • Faster onboarding
    • This approach saves time and money because developers are not needing to visit many different repositories in order to do their work and they don’t need to know where those repositories are because everything is where they need it.
  • Easier maintenance
    • In all of the cases mentioned above, maintenance is made much faster by removing the separate software components and placing them into the larger repository so that they can be maintained and tested alongside it.
  • Better integration testing
    • Historically one of the areas where we are weak is software integration testing. When more of the components are in the same repository it is much easier to use the continuous integration system to run tests both on them and between them. This leads to better security.
2 Likes