search

IntersectMBO / ouroboros-consensus

Implementation of a Consensus Layer for the Ouroboros family of protocols
https://ouroboros-consensus.cardano.intersectmbo.org
Apache License 2.0
36 stars 23 forks source link

Move db-analyser and db-synthesiser to a separate repository #1333

Open dnadales opened 2 years ago

dnadales commented 2 years ago

The db-analyser tool is used with chains produced with a certain version of cardano-node that is usually not the master version of this repository. Whenever we want to develop a new feature for db-analyser we have to develop on top of an older version of ouroboros-network (eg https://github.com/input-output-hk/ouroboros-network/pull/4014). Similarly, when we want to analyze the mainnet chain, we usually have to checkout an older commit of this repository, otherwise, we run into problems such as incompatible serialisation formats or ledger rules.

I'd propose to move db-analyzer to a different repository. Two options are:

By doing this, the master version of the repository in which db-analyser is, will be closer to the master version of the node, and safe from breaking changes in the networking, consensus, and ledger layers.

This will also help reduce the surface area of consensus.

nfrisby commented 2 years ago

Whenever we want to develop a new feature for db-analyser we have to develop on top of an older version of ouroboros-network (eg PR 4014)

I think we can usually develop on master. Moreover, PR 4014 was a particularly extreme case, because db-analyser was relocated&rewritten on the main branch.

But I don't have a particularly strong preference either way. I do think of db-analyser as requiring "eventual integration" of changes, just like eg cardano-node does. Having it in our repo just makes it that much more likely that we'll do that integration incrementally&in-the-moment.

I think it'd be cleanest in it's own repo, but I think maintaining it in cardano-node would ultimately be the least confusing: if you're analysing a state folder built by some node, then you should use the db-analyser from that node's commit.

Do @kosyrevSerge and @mgmeier agree?

dnadales commented 2 years ago

I think it'd be cleanest in it's own repo, but I think maintaining it in cardano-node would ultimately be the least confusing: if you're analysing a state folder built by some node, then you should use the db-analyser from that node's commit.

Ok, I'm glad to hear this idea was not totally crazy.