it is cumbersome to merge pallet changes with PR's on multiple repos. We usually first test with unit tests in pallets repo, but then we need integration tests with bot-community script which requires a PR in the encointer-node repo, but CI can't pass before the pallet PR is merged unless we hack in an intermediate cargo patch which is just ugly.
no_std clashes caused by pallets can sometimes only be detected after integration in to runtime
We want to align business logic on solochain and parachain testnets and mainnet. In the best case, we align spec-versions for our respective runtimes. So keeping all runtimes in the same repo with the same spec version makes sense
We now follow polkadot release branch dependencies (should be done even for solochain substrate dep), so upgrades would be more straightforward if all was in the same repog
It is often not obvious if an issue should be submitted to pallet, node, or parachain repo
Con
pallet PRs, which are currently very simple, will take longer to merge as they demand simultaneous integration into the node/parachain (but that's how continuous integration should be....)
bumping substrate might be a bit more complicated, as we need update the node & the parachain
monorepo name
suggestion:
create fresh repo encointer/encointer
archive encointer-node, pallets, encointer-parachain and (before archiving ;-) redirect in README)
alternative ideas:
encointer/backend
encointer/platform
encointer/network
what repos to merge
encointer-node
encointer-parachain
pallets
(worker)...later
It may make sense to move community specfiles out of our code repo into its own repo encointer/communities as there is no depenmdency on this data from within the monorepo
what not to include in a monorepo and why
mobile app: Has its own release cycle which is loosely coupled with our runtimes
encointer-js: Is not a dependency of anything else in the monorepo, so we may want to leave this separate
open questions
bazaar integration tests are still a mess (see intermediate work #174). May be better to separate e2e testing (integrate functionality into bot-community.py) and helpers (register-business, register-offering... in scripts folder)
similar decision to take for democracy stuff: include democracy e2e into bot-communities.py?
monorepo structure
client/
client/encointer-api-client-extension
tests (e2e testing of parachain and solochain)
tests/py/ (only what is needed for integration testing, no production tools -> they should go to ./scripts)
tests/py/encointer (formerly py_client)
tests/py/tools/faucet.py, phase.py
tests/py/bot-communities/bot-communities.py (to be split into parts to be extendable)
pallets/
solochain/node (rename crate to `encointer-solochain`)
solochain/runtime
solochain/chainspecs
parachain/node (collator: rename crate to `encointer-parachain`)
parachain/runtime/encointer
parachain/runtime/launch
parachain/runtime/common
parachain/chainspecs
sidechain/node (future place for "worker/validateer")
sidechain/runtime (sgx-runtime)
scripts/* + voucher.py batch.py endorse dump-accounts dump-balances .....
Why a monorepo?
Pro:
no_stdclashes caused by pallets can sometimes only be detected after integration in to runtimeCon
monorepo name
suggestion:
alternative ideas:
what repos to merge
It may make sense to move community specfiles out of our code repo into its own repo
encointer/communitiesas there is no depenmdency on this data from within the monorepowhat not to include in a monorepo and why
open questions
monorepo structure
communities repo structure