Development meeting held @ 3PM UTC in grin/Dev channel on Gitter, full chat transcript here. Meeting lasted ~ 60 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
- davidburkett
- garyyu
- hashmap
- ignopeverell
- jaspervdm
- kargakis
- lehnberg
- mcdallas
- quentinlesceller
- yeastplume
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
- ignopeverell: It's been mostly fixing loose ends and doing testing before 1.1.0, with various small improvements. #2780 is a pretty good one from @hashmap as well, and good timing. @yeastplume is almost done with the invoicing API too.
Proposed agenda accepted. @davidburkett added slate version to Other Questions.
- quentinlesceller: Just got back from holidays, I still have a small issue with windows environment variable but nothing blocking. Hopefully beginning of the week this is fixed and we're up and running on Azure Pipelines. Next steps would be to merge then link azure-pipeline and maybe do a test release to ensure everything is working well.
- yeastplume: Sounds like a candidate for 1.1.0-beta-2. Were you intending to give the wallet the same treatment? If not, I can just use the old build system for 1.1.0 for now.
- quentinlesceller: Yes, I think we can safely target end of the week for me. Once /grin is up and running, next up would be integration with grin-wallet, which shouldn't be long after.
- kargakis: Done
- grin issue: mimblewimble/grin#2768
- grin-wallet issue: mimblewimble/grin-wallet#86
- davidburkett: Done. I single-handedly decided on the phase-out strategy, so please review that and make sure there are no disagreements.
- ignopeverell: Yes, a few reviews would probably be a good thing.
- lehnberg: Let's track reviews in an issue and close once people are happy with it.
- ignopeverell: Coinspect has asked for an additional week to finish the report. They've reviewed the wallet and are working on some final findings.
- ignopeverell: v1.0.0 it has not been released yet but is looking more and more stable. I believe @yeastplume was suggesting another beta, which would be a good idea at this stage. Looks like we're getting pretty close to me.
- jaspervdm: Should we wait for the final Coinspect report and implement all fixes before v1.1 is released?
- ignopeverell: Would be good but I wouldn't want to depend on further delay from them, so maybe only if the report comes soon after beta2.
- jaspervdm: Makes sense.
- lehnberg: Exchanges have been asking for more info, like what the specific API changes needed to be supported by them etc. I could write something up, but don’t have enough answers at this stage, so would be good to maybe sit down and flush this out with someone who has.
- ignopeverell: Let's do it together, you, me and @yeastplume. We can each fill up different parts: you can take the organizational aspects, I can take grin and @yeastplume grin-wallet.
- quentinlesceller: Would be nice to have all this on https://grin-tech.org and keep official announcements and download links to binaries there.
- hashmap: Update on my 1.1.1. plans before I have to leave: I’d like to reduce node’s cpu usage, 2 days ago it was 65% on my mac, my goal is 5%.
- ignopeverell: As soon as 1.1.0 is released we'll have 2 things to track:
- Improvements to 1.1.0 that will be 1.1.x;
- Our first hard fork is nearing, we'll have to start a 2.0.x branch or at least a set of PRs to start with. We need to start discussing Cuckaroo tweaks soon. And of course the
if now > 6 months later { boom }in the code.
- lehnberg: Do you have a target for a version you would like i2p to be included in yet? Anything consensus breaking?
- ignopeverell: No, only slight tweaks to the peer message but those shouldn't even impact peer negotiation, being a feature. Nodes will either be pure TCP only, both, or i2p only. With "both" being a bridge between the networks. It's not targeted for 1.1.0, the first version with it will likely have it entirely optional,maybe a 1.2.0 if it's ready on time? But could also go as a 1.1.x.
- lehnberg: Going with both for the time being with a slow migration over to full i2p at some point if it works as it should seems like a sensible goal to aim for.
- ignopeverell: Indeed.
- This is a truncated summary, i2p topics including NAT traversal, seeding, avoiding network splits, and opting for an i2p-only route were discussed.
- yeastplume: Do we have any particular problems with the current way we do it?
- lehnberg: I created the issue in question to discuss, I for one don't actually understand the current approach.
- davidburkett: You're not the only one.
- yeastplume: Fixes to master, aiming for next point release, branch for next minor release, put breaking changes there, merge master into branch once in a while to keep it up to date.
- antiochp: The final deployment step is something I'm not 100% clear on with our current approach - do we merge back into master and then deploy from there (for 1.1.0 for example)? or are we deploying 1.1.0 from the 1.1.0 branch?
- kargakis: Let's get this documented properly. It should be part of CONTRIBUTING or a different doc linked in CONTRIBUTING.
- ignopeverell: Good idea, I will do this. There is a method to this madness, we tried several ways actually. I'm not aware of an approach that doesn't require either merge (with possible snafus) or cherry picking (with possible snafus). Cherry picks isn't great for open source, you have to be very diligent and practically not allow a PR unless it comes with cherry-picks for all active branches. So you get N PRs instead of 1.
- garyyu: mimblewimble/grin-wallet#95
- yeastplume: There's versioning for the V2 api, also I didn't want to have the version function return the specific version the client is running, seems that would just make life a little bit easier for anyone looking for exploits should a particular version have something known to be exploitable. 1.1 can just check whether the v2 version function exists. If not, just send slate version 0. The v2 version (and onwards) function returns the current slate version.
- davidburkett: I guess my proposal is move 'check_version' out of /v2/. Just have /version.
- yeastplume: Ahh okay. I can see that. I'm for some reason assuming /v2/ will cover all versions of the api. v1 is http, v2 is json-rpc, but there will be versions within that, retrieved via the check_version function, which will always be at the v2 endpoint, that's kind of what I was assuming. check_version is a json-rpc function like all v2 api calls. It's documented in the api rustdoc. I don't think we necessarily want to change the endpoint each time there's a change to the version API, that's what that version function is for.
Meeting adjourned.