Agenda: Development, Mar 03 2020

[lehnberg]

Solicit suggestions for agenda items for the Development meeting to be held on Tuesday Feb 18 @ 15:00 UTC in grincoin#dev channel on Keybase. Please comment to provide topics or suggestions.

Proposed agenda

1. A yeasty reminiscence
2. Agenda review
3. Action point follow ups from previous meetings
   • Research linking commitments in grinscan.net @jaspervdm
   • Triaging research @lehnberg
   • Use of stable tag? @antiochp
   • croaring failing on ci? @quentinlesceller
4. How to handle upgrades after 5.0.0
   • Are we really ready to give up on the scheduled hard forks?
   • If so, how are we handling upgrades and releases?
   • What do we do when we break consensus?
   • Should we consider adding additional scheduled hard forks beyond 5.0.0?
   • Must all consensus changes be approved at a governance meeting, or should miners, nodes, etc have the option of signaling support for ideas?
   • Should code be made more supportive of soft forks? Example: One way of making the code more soft-fork-ready is to treat all non-standard kernel types as valid as long as they have valid signatures.
5. Planning
   1. Grin v4.0.0
   2. Grin v5.0.0 and beyond
      • In less than a year, we'll have completed our last scheduled hard fork. What are the key improvements we want to make sure to have gotten in before that?
      • And how do we plan to make it happen?
6. Sample project:
   • Moving all the configuration and startup, etc into a separate project altogether, making 'grin' and 'grin-wallet' library projects.
   • Then we have a top-level project that handles the setup and environment for both and produces the grin-wallet and grin binaries as separate targets.
   • It would also include all integration tests that use both, as well as another binary/lib that starts up servers and wallets quietly and exposes their APIs for other consumers (e.g. developers of wallets).
7. Testing
8. /packaging
9. Other questions

[lehnberg]

I would like to add two topics to next week's meeting:

1. The state of Grin at v5.0.0 and beyond. It might seem like far far away in the future, but in less than a year, we'll have completed our last scheduled hard fork, and it will become much harder to handle consensus breaking changes. What is our wish list for then? What are the key improvements we want to make sure to have gotten in before that? And how do we plan to make it happen? Transaction building is one example: Are we seriously going to deprecate unsafe methods? If so, we need to start making this clear immediately. What about slate structure? What are the other things we should be targeting in our remaining two scheduled upgrades?
2. Upgrades after 5.0.0. Are we really ready to give up on the scheduled hard forks? If so, how are we handling upgrades and releases? What do we do when we break consensus? Should we consider adding additional scheduled hard forks beyond 5.0.0?

[yeastplume]

At the risk of pushing the meeting out, also wouldn't mind discussing this, if we're over time with all of the other issues also happy to leave this until the following dev meeting:

Copied from keybase chat.. note I'm not necessarily advocating this as the best idea ever as it comes with a lot of cons, but wouldn't mind discussing it a bit.

I'm just putting together a sample project that includes the node and the wallet libs, and there's obviously a hellish amount of redundancy there when it comes to config file setup etc, so I had a thought.
What if we moved all of the configuration and startup, etc into a separate project altogether. So what's currently 'grin' and 'grin-wallet' just become library projects. Then we have a top-level project that handles the setup and environment for both and produces the grin-wallet and grin binaries as separate targets. It would also include all integration tests that use both, as well as another binary/lib that starts up servers and wallets quietly and exposes their APIs for other consumers (e.g. developers of wallets).

[DavidBurkett]

2. Upgrades after 5.0.0. Are we really ready to give up on the scheduled hard forks? If so, how are we handling upgrades and releases? What do we do when we break consensus? Should we consider adding additional scheduled hard forks beyond 5.0.0?

I would like to add a few points of discussion to this topic:

• Must all consensus changes be approved at a governance meeting, or should miners, nodes, etc have the option of signaling support for ideas?
• Should all consensus changes be done through hard forks, or should we make our code more supportive of soft forks? Example: One way of making the code more soft-fork-ready is to treat all non-standard kernel types as valid as long as they have valid signatures.

[lehnberg]

Agenda updated