Create Repository Structure #1
Conversation
agouin
requested review from
AdityaSripal,
chatton,
jackzampolin and
womensrights
…c-apps into bd21/create-repository-structure
| - A release and tag for _App A_ ought not be blocked on changes in other unrelated or upstream apps | ||
| - Version management must be able to be handled independently. i.e. An _App A_ can upgrade to `ibc-go v8` and release a tag against it, while _App B_ may remain unsupported for `v8`. | ||
| - Teams with general write access to the repo should not be authorized to write to apps that they do not maintain (only default branch/tags/etc). Of course, PRs welcome :-) | ||
|
|
There was a problem hiding this comment.
Will it then be up to the specific app developers to communicate the versioning and compatibility of their apps with ibc-go releases or should there be some information collated for all apps in the repo? i.e. as a user, is there an easy way for me to come to this repo and see which apps will work with which release
There was a problem hiding this comment.
Would it be helpful if this issue is implemented for ibc-go v8.0.0? cc @damiannolan
There was a problem hiding this comment.
Will it then be up to the specific app developers to communicate the versioning and compatibility of their apps with ibc-go releases or should there be some information collated for all apps in the repo? i.e. as a user, is there an easy way for me to come to this repo and see which apps will work with which release
This is a great call out. This will need to be coordinated and collated for the repo, such as with a version matrix on the README. But we can keep the release cycles separate for different ibc-apps similar to how the Cosmos SDK repo does for different modules.
|
|
||
|
|
||
| ## New contributer approval process | ||
| - [ ] Submit a Github issue titled "I should be a maintainer because..." |
There was a problem hiding this comment.
I think it would be good to give a bit of an indication of why someone would be granted write access. Some thoughts I have:
- Actively developing an ibc app or middleware that is / will be in this repo
- Has previously made a substantial contribution to an app housed in the repo and plans to contribute more going forwards
- Already has write access to an app that will move into the repo
|
|
||
| IBC Modules are self-contained applications that enable packets to be sent to and received from other IBC-enabled chains. IBC application developers do not need to concern themselves with the low-level details of clients, connections, and proof verification. | ||
|
|
||
| IBC Middleware are self-contained modules that sit between core IBC and an underlying IBC application. This allows developers to customize lower-level packet handling. Multiple middleware modules can be chained together. |
There was a problem hiding this comment.
Maybe link to the middleware spec?
There was a problem hiding this comment.
Why the spec? Would it not make more sense to point to ibc-go middleware docs?
Ditto for apps btw
There was a problem hiding this comment.
Agreed the docs are probably more user friendly
| An [example IBC app](./examples/hello-world/) | ||
|
|
||
|
|
||
| ## List of Apps |
There was a problem hiding this comment.
Maybe this should go earlier in the read me? Not a big point but I can imagine if you already know about ibc you might just want to know which apps and middleware are in the repo asap
| 🌌🌌🌌🌌 How to Use this repo | ||
| ============================= | ||
|
|
||
| If you'd like to include software in this repo, please see [contributing](../ibc-apps/CONTRIBUTING.md). |
There was a problem hiding this comment.
Should there be some information here about how to actually import the modules in the repo? Users would be not just contributors but chain devs
| @@ -1,2 +1,64 @@ | |||
| # ibc-apps | |||
| IBC applications and middleware for Cosmos SDK chains | |||
|
|
|||
|  | |||
There was a problem hiding this comment.
This is just a general comment which probably needs a bit more discussion - do we want their to be a feeling of coherence between ibc-apps and ibc-go? Right now the readme's have a different flow of content and different descriptions of ibc for example. If we want a unified feel, I would suggest we align on this and that isn't to say ibc-go just sets the tone but we can adapt both in parallel?
There was a problem hiding this comment.
I think we should aim for a unified feel in terms of readme, documentation etc. Could be good to have teams sync on this given that the README revamp for ibc-go is still ongoing. cc @crodriguezvega
| 🌌🌌🌌 What is it? | ||
| ================== | ||
|
|
||
| ### What is IBC? |
There was a problem hiding this comment.
Should we explain this here? Feel like one sentence about IBC and one about ibc-go would be enough with references for further prerequisite readings if the reader needs it. Given the comment above wrt coherency between ibc-go and ibc-apps, how about we use this:
The Inter-Blockchain Communication protocol (IBC) allows blockchains to talk to each other. This end-to-end, connection-oriented, stateful protocol provides reliable, ordered, and authenticated communication between heterogeneous blockchains.
This IBC implementation in Golang is built as a Cosmos SDK module. To understand more about how to use the ibc-go module as well as about the IBC protocol, please check out the Interchain Developer Academy section on IBC, or our docs."
Could be rephrased but likely good to have something similar in both repos
|
|
||
| IBC applications and middleware for Cosmos SDK blockchains | ||
|
|
||
| 🌌 Why have an ibc-apps repo? |
There was a problem hiding this comment.
This paragraph and the next talk about IBC and ibc-go without first defining them, how about we swap the order?
- What is IBC? (short and succinct)
- Why have an ibc-apps repo?
- Who's it for?
- How to use this repo?
- Bonus content
Should be removed now |
|
hey @tmsdkeys @womensrights @chatton, I've granted you write access to the feature branch. I don't have any more strong opinions about the layout or wording of this repository. Feel free to edit as needed - let's merge this tomorrow on Tuesday. Invitaiton: https://github.com/bd21/ibc-apps/invitations |
|
|
||
| IBC Modules are self-contained applications that enable packets to be sent to and received from other IBC-enabled chains. IBC application developers do not need to concern themselves with the low-level details of clients, connections, and proof verification. | ||
|
|
||
| IBC Middleware are self-contained modules that sit between core IBC and an underlying IBC application. This allows developers to customize lower-level packet handling. Multiple middleware modules can be chained together. |
There was a problem hiding this comment.
Agreed the docs are probably more user friendly
There was a problem hiding this comment.
Should we call this directory apps instead of modules?
There was a problem hiding this comment.
I like the differentiation between modules vs. middleware, both of which are Apps
There was a problem hiding this comment.
What about having the base apps and the middleware both under an apps directory? What top level directories will be shared between the apps?
|
Merging this so we can move forward with bootstrapping the repo. Please open new PRs if necessary for unresolved comments. |
|
|
||
| ## New contributer approval process | ||
| - [ ] Submit a Github issue titled "I should be a maintainer because..." | ||
| - [ ] After approval, write privileges will be granted to a member of an external team. |
There was a problem hiding this comment.
Is this the team who opened the issue?
| ## New contributer approval process | ||
| - [ ] Submit a Github issue titled "I should be a maintainer because..." | ||
| - [ ] After approval, write privileges will be granted to a member of an external team. | ||
| - [ ] Merging PRs will require approval from more than one team |
There was a problem hiding this comment.
What's the intention behind this requirement? Trying to gauge what issue it is trying to solve
| - [ ] After approval, write privileges will be granted to a member of an external team. | ||
| - [ ] Merging PRs will require approval from more than one team | ||
|
|
||
| Privileges will be revoked in case of failure to comply with the [Code of Conduct](../CODE_OF_CONDUCT.md) |
There was a problem hiding this comment.
Who makes this judgement? In my experience, violations of code of conduct are usually not so straight forward and hard to enforce when no one is given the authority to make the judgement
There was a problem hiding this comment.
What about having the base apps and the middleware both under an apps directory? What top level directories will be shared between the apps?
No description provided.