Skip to content

Latest commit

 

History

History
91 lines (67 loc) · 6.2 KB

20190219-meeting-development.md

File metadata and controls

91 lines (67 loc) · 6.2 KB
Raw

Meeting Notes: Development, Feb 19 2019

Development meeting held @ 3PM UTC in grin/Dev channel on Gitter, full chat transcript here. Meeting lasted ~ 90 min.

Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.

Community attendance:

  • antiochp
  • bladedoyle
  • davidburkett
  • garyyu
  • hashmap
  • jaspervdm
  • noble_block_twitter
  • quentinlesceller
  • rentenmark
  • tromp
  • yeastplume

(apologies if I missed someone - submit a PR or contact @lehnberg to add)

Agenda points & Actions

1. Retrospective

  • @yeastplume: Covering for Igno this week. Marching on as usual. For my own part I've been working on getting the wallet split out, which I think is done now, and moving on to the last points that need addressing for a windows release. Other than that chain is ticking along and had its one month birthday without any explosions, which I guess is something to celebrate. Others?
  • antiochp:
    • adding a global file lock (so we don't corrupt the data with multiple grin servers)
    • getting back up to speed on Dandelion++
    • mapping peers by ip (and not by port)
    • reviewing various PRs
  • hashmap: Fixed 4 peers issue (for nat’d nodes), stratum issue with partial read, some rest api refactoring.
  • tromp: I've been discussing miner improvements with photon and lolliedieb. and am working on cuckatoo32 support.

2. Agenda review

Proposed agenda accepted, added "Error management" as an additional point on @hashmap's request.

3. Action point follow-up

3.1 Update CONTRIBUTING.md with new requirements

  • yeastplume: Done.

4. Grin v1.0.x

  • yeastplume: The next point release is 1.0.2. I've been working more or less exclusively on 1.1.0 changes. Not sure what our plans are for when we do a 1.0.2 release and what will be in it. I guess this is the time to discuss.
  • antiochp: Milestone: https://github.com/mimblewimble/grin/milestone/10
    • there's some cleanup and maybe a couple of bugfixes in 1.0.2
  • davidburkett: Hashmap's peer fixes are a must. And I would argue should be done soon. Many (most?) users are behind NAT, and can’t maintain any peers, resulting in their nodes falling behind.
  • yeastplume: Looks as if a 1.0.2 could be done at any time, really. there are a couple of things that would be good to get in, and then a release seems timely. Whatever is in roughly around this time makes it.

Decision: v1.0.2

Target for a release sometime next week.

5. Grin v1.1.0

  • yeastplume: wallet being split off into a separate repo (which is done now but needs review), and Windows support (which is getting there). As far as timing, I'd say it's still a few weeks off, given we need to merge all changes back into the 1.0.x and perform a decent round of testing on it. Everyone please update whatever issues to reflect the milestone.
  • antiochp: Dandelion++ also a candidate there.
  • hashmap: New stratum needs proper testing, it’s tagged already (pr only). My 2 main issues are high cpu usage (which could be improved by increasing sleep time in some places, but a proper fix is to rewite p2p io whch opens a can of worms), and pmmr persistence durability. Now 1 peer consumes ~ 1% cpu.
  • tromp: Wallet is still defaulting to height locked kernels where it should use plain kernels. Fee is the same, but it's wasting bandidth and should be changed.
    • antiochp: The bandwidth bit is a trivial change, the backend storage is far from trivial, as there is no code in place to handle different MMR element sizes.
  • yeastplume: As far as the 1.1.0 item, update issues and we can review where we are more definitively at the next dev meeting. That sounds good?

6. Error management

  • yeastplume: I had thought we'd had this discussion a while ago, and we were starting to use ErrorKind enums as the best solution. It's in a few crates, but not consistent.
    • hashmap: Yeah, a year ago. We have too many error wrappers. Even though we uniform them it’s still pain. Like dozen keychain::Error.
    • yeastplume: Yeah, each crate is wrapping every error from all other crates. I guess having a single crate for all errors is a possibility. But then we're going to end up with a huge ErrorKind enum. From a usage perspective, I don't see that as a huge issue, so long as the error crate doesn't itself have any dependencies on grin crates.
    • quentinlesceller: Any examples?
    • davidburkett: So, everything in keychain would throw a keychain::Error, but they would all unwrap to a ErrorKind::keychain?
    • antiochp: I'm actually not opposed to having each crate wrap errors from dependent crates - its part of the api. I was just looking at something sort of related to this - https://doc.rust-lang.org/std/io/enum.ErrorKind.html. There's an Other ErrorKind in there (for std::io) that can wrap anything.
    • hashmap: I could volunter to summarize different approaches and suggest couple for the next meeting.

meeting agreed.

7. Other questions

7.1 Wallets

  • garyyu: With wallet separated from node, how will we handle different versions of wallet and node running on the same system?
    • yeastplume: Wallet lib relies on mostly core, keychain, store and util from core. We might want to ensure the grin node reports its version properly, so the wallet can fail gracefully.
  • garyyuu: With multuple projcts, I think we need a release page on our website, to hold 3 binaries for one release: server, wallet, miner, instead of on each github project.
    • yeastplume: sure, makes sense.
  • davidburkett: The user should still be able to install an old wallet, with a new node. Correct?
    • yeastplume: Not sure we can guarantee that for perpetuity, but we can ensure we handle needed updates gracefully and prompt user to upgrade if necessary.
    • hashmap: We might drop some apis in the future.

Meeting adjourned.