Golang Core Dev Team - August 13, 2018#678
Conversation
ghost
assigned
…ore-dev-team-weekly.md
daviddias
changed the title
|
I refined my notes a bit. |
|
Sorry for the delay here, I'm pretty sure I can't push to this PR, could someone add my notes please? |
add schomatis notes
|
@schomatis |
|
@schomatis gave you access as well for future times! |
|
|
||
| @marten-seemann (not attending) | ||
| - Done: | ||
| - various QUIC improvements |
There was a problem hiding this comment.
@marten-seemann, mind enumerating here what improvements were made?
| - Fixed a few bugs | ||
| - Notable: update gogo protobuf | ||
| - Blocked: | ||
| - https://github.com/multiformats/multiaddr/pull/68 <- @daviddias P3 |
| - Done: | ||
| - Reviewed a bunch of PRs | ||
| - Responded to/triaged a bunch of issues | ||
| - Fixed a few bugs |
There was a problem hiding this comment.
Any notable bug (that people were eagerly waiting)?
| - Next: | ||
| - More of the same | ||
| - CIDv1 | ||
| - Finish the protocol negotiation spec |
There was a problem hiding this comment.
@Stebalien remind me, is this related with Multistream?
There was a problem hiding this comment.
Yes. It's the "next" version of protocol negotiation.
There was a problem hiding this comment.
Interesting. I didn't know that was urgent/P0
There was a problem hiding this comment.
The sooner we fix it, the better. Every other protocol we have relies on it and we currently (in go at least) try rather hard to reuse streams as creating new ones is expensive (in terms of bandwidth).
For context, inefficient stream negotiation means we need things like libp2p/go-libp2p-kad-dht#92 instead of libp2p/go-libp2p-kad-dht#167.
| - Studied part of the `gx`/`gx-go` code and workflow, how can we | ||
| make the package manager more user friendly? | ||
| - Next: | ||
| - Start submitting some PRs in `gx`/`gx-go` with documentation |
There was a problem hiding this comment.
Does this mean you are fully focused on gx, @schomatis ?
There was a problem hiding this comment.
For the moment, yes, but I still need to keep an eye on some Badger and go-unixfs issues.
| @bigs | ||
| - Done: | ||
| - Research into virtual network topologies w/ openvswitch/iptools | ||
| -> @daviddias introduce travis & jacobheun |
There was a problem hiding this comment.
Let's do Github Style!
@travisperson @jacobheun, please meet @bigs. I'm sure you have crossed each other or even met at the IPFS Dev Meetings.
- @bigs is doing a lot of IPTB work for libp2p testing
- @travisperson is doing a lot of IPTB work to add support for js-ipfs daemons (Node.js) and js-ipfs browser nodes
- @jacobheun is looking into designing interop tests that can be used by go-libp2p, js-libp2p and rust-libp2p
It would be great to have you all sync soon to make sure that we leverage everyone's focus and don't get duplicated work done.
| - Next: | ||
| - Durable implementation of namespaced virtual networking in go-netdef | ||
| - Write rendered network config to a file for easy reversal | ||
| - Learn virtual NATing? |
There was a problem hiding this comment.
If you end up writing notes, post them on libp2p/notes perhaps?
| - Prevents use from building on non-Windows without cgo | ||
| - Having mutliple implimentations for the same subcommand seems non-ideal | ||
| - Next: | ||
| - Schedule to speak with David :^) |
| - infra stuff, nothing go related | ||
| - blocked | ||
| - nothing go related :) | ||
| - next |
There was a problem hiding this comment.
@lgierth will you have bandwidth soon to pick ipfs/kubo#4595 back up?
There was a problem hiding this comment.
Yes definitely until end-of-August -- how badly are you blocked?
There was a problem hiding this comment.
I'm getting ready to do end to end validation, which needs the branch. I started implementing the endpoints in js, but it doesn't currently have refs support. I can look at getting the existing go branch running locally to at least get e2e validation happening. If we can get it live by mid September I think we can still get js peer/content delegated routing out by end of the quarter.
| - Blocked: | ||
| - https://github.com/multiformats/multiaddr/pull/68 <- @daviddias P3 | ||
| - https://github.com/multiformats/multiaddr/pull/68#issuecomment-401971665 | ||
| - Next: |
There was a problem hiding this comment.
@Stebalien also, as discussed during the call. Please do the drawing (even if on paper) of something like:
https://github.com/ipfs/js-ipfs#code-architecture-and-folder-structure
But for go. Contemplating what is legacy, what is next, including:
- go-ipfs-cli
- go-ipfs-cmds
- go-ipfs-api
- go-ipfs-core
- go-ipfs daemon
- go-ipfs-http-api
- go-ipfs-http-gateway
And anything else that it is there.
There was a problem hiding this comment.
Bonus points if you do another for how things are pieced together. Like this one https://github.com/ipfs/js-ipfs#ipfs-core-architecture
There was a problem hiding this comment.
You can do it on paper, I can create the ascii version
There was a problem hiding this comment.
There was a problem hiding this comment.
Dotted means "likely going away". The "Legacy" parts are thin wrappers around some commands to translate between the new system and the old system. The grayed-out parts on the "daemon" diagram are there to show that the code is all the same, it's just that we turn some pieces on and some pieces off depending on whether we're running on the client or the server.
6 participants
The link to the recording is not there yet.