Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

OKRs - 2019 Q1 Go Core Dev #794

Merged
merged 7 commits into from
Mar 18, 2019
Merged

OKRs - 2019 Q1 Go Core Dev #794

merged 7 commits into from
Mar 18, 2019

Conversation

eingenito
Copy link
Contributor

@eingenito eingenito commented Dec 10, 2018

Go IPFS/IPLD Core Dev OKRs

It's time for us to work on our OKRs for Q1 2019. We should keep in mind our WG goals as expressed in our roadmap. We'll use this PR for proposals and discussions of OKRs the next quarter.

ref #792

@eingenito
Copy link
Contributor Author

I've just assigned this issue to the IPFS core dev team. @warpfork I'm mentioning you here; I'm not sure if IPLD has separate OKRs.

First if you had OKRs assigned to you for Q4 2018 please review and update the Q4 column in the Q4 2018 OKRs Spreadsheet to make sure you agree with the completion status of the OKRs. I copied the predicted value that we did mid-quarter into this column.

@eingenito
Copy link
Contributor Author

I'm going to seed this discussion with the leftover OKRs from Q4 2018. I've crossed ones out that I don't understand or that I think are no longer (or never really were) a priority. This is just opinion and some of it uninformed so feel free to champion and of these OKRs that you think are still important.

Data transfer is fast and efficient

  • It takes less than 48 hours to transfer 1TB dataset over Fast Ethernet (100Mbps)
  • There is a spec for GraphSync falls outside of this WG
  • Bitswap refactor + improvements reduce number of duplicate blocks downloaded by 75%
  • There is a prototype implementation of GraphSync for go-ipfs unlikely for Q1
     

Adding and providing large data sets works efficiently

  • Create Provider Strategies system that is solely responsible for providing
  • Have a solid interface for transactions by Nov 10 unlikely for Q1
  • Able to add npm, tr-wikipedia without turning off providing
  • Create 4 use case breakdowns about desired expirience with providing/resolving not a priority
  • Support for complex/flexible pinning strategies (ex pinning a graph to a certain depth) duplicative and unclear
  • Transactions to blockstore support GC and pinning in parallel with adding data unlikely for Q1
     

Datastore works efficiently for large data sets

  • Final go/no-go decision on Badger (full design comparison vs other options + final decision) yes please
  • Ongoing fuzzer/CI jobs running on ipfs datastore solution(s) is this the infra testing project?
     

go-ipfs becomes a well maintained project

  • Every non-trivial PR is first reviewed by someone other than @Stebalien before he looks at it.
  • Every issue on https://waffle.io/ipfs/go-ipfs gets triaged (reviewed and labeled following https://github.com/ipfs/pm/blob/master/GOLANG_CORE_DEV_MGMT.md) clearly need a solution, powerful forces oppose Waffle
  • A Lead Maintainer Protocol equivalent is proposed, reviewed by the team, merged and implemented maybe too specific?
  • The Go Contributing Guidelines are updated to meet expecations from Core Devs and help new contributors (e.g include PR templates)
  • Unit tests and code coverage tests are run efficiently using CI unclear, or already achieved
  • There is an up-to-date Architecture Diagram of the Go implementation of IPFS that links packages to subsystems to workflows possible, is this still a priority?
  • go-unixfs is more maintainable with improved code, comments and documentation done?
     

gx becomes a beloved tool by the Go Core Contributors Travis are you still working on this?

  • You can update a minor version of a transitive dependancy without updating intermediate dependancies _is this still a goal?
  • go-ipfs doesn't have checked-in gx paths
     

Complete outstanding endeavours that are still high priorities from Q3

  • base32 is supported and enabled by default !
  • MFS behavior and implementation is performant and correct I don't understand this OKR
  • Add mutable methods (r+w) to the new mount implementation and get it building+tested on all supported platforms I don't know if this is still a priority

@daviddias daviddias changed the title 2019 Q1 Go Core Dev OKRs OKRs - 2019 Q1 Go Core Dev Dec 11, 2018
OKR/GO_CORE.md Outdated
* Implement provider strategy such that a user can add (and provide) npm or tr-wikipedia without turning off providing and without significantly impacting finding content

### Datastore works efficiently for large data sets
* Final go/no-go decision on Badger (full design comparison vs other options + final decision)
Copy link
Contributor Author

@eingenito eingenito Dec 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be something like:

A fast, stable datastore capable of supporting large data sets > (?)TB has been selected and released as experimental

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's pretty much where badger is right now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right - good point. Maybe this OKR should be about a new default datastore that has the right characteristics for large data sets.

OKR/GO_CORE.md Outdated
* A work-tracking process is adopted that allows the team to easily track the highest priority unclaimed issues, see the status of in progress work, and know which PRs need review, easily.

### gx becomes a beloved tool by the Go Core Contributors Travis are you still working on this?
* go-ipfs doesn't have checked-in gx paths
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@travisperson is this still a goal of yours? I don't know if you're still working on gx udpates or not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a goal should be to either onboard a contributor/full-time maintainer excited about pushing gx forward (@warpfork - any ideas from recent conferences?) and really double down on making this a powerful proof of concept that is friendly and useful for go developers, or adopt @Stebalien's proposal to optimize for developer velocity in the short/mid term.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah - absolutely agree; one of those is going to be an OKR. And possibly even both.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Optimizing developer velocity" could be the objective. The KR would be "go-ipfs developers are no longer adversly affected by gx" (with some significant rewording). That way, either getting a maintainer or moving away from gx are valid solutions.

@momack2
Copy link
Contributor

momack2 commented Dec 14, 2018

@hsanjuan @alanshaw @bigs curious if you have any requests for go-ipfs Q1 okrs, or see any opportunity to align efforts?

@hannahhoward
Copy link

@eingenito while I don't feel able to move on graphsync until there's a spec (still none), what I would like to do is apply "DAG smarts" to driving bitswap. Meaning, if I'm walking the DAG, instead of simply driving Bitswap with a session, I might use one of Bitswap lower level APIs in concert with smarts about the DAG -- namely, a peer that provides a parent is likely ot have a child, and probably some siblings. This also entails completing the seperation/refactor of bitswap into lower and higher level components -- "Just as for blocks from specific peers" low-level bitswap, and sessions/block getting interface high-level bitswap. If I had to express this as an OKR, I'd say:

"Transfer of Merkle DAGs is faster using Bitswap than asking for blocks individually"

As an aside, this is also important for supporting providing strategies which are not "provide every block in a tree"

@bigs
Copy link
Contributor

bigs commented Dec 14, 2018

@momack2 would absolutely love some collaboration on the IPTB work i'm doing. particularly bringing IPTB to a clustered environment!

@vmx
Copy link
Member

vmx commented Dec 17, 2018

@hannahhoward Being the one working on Graphsync from the JS side, I can only say that this sounds like a great plan. Indeed the won't be a fully fleshed out Graphsync spec soon. I will also rather concentrate on making small steps (i.e. being able to replace Bitswap with some other system), rather than thinking top down. The existing Graphsync proposals will be a guidance for me though.

@eingenito
Copy link
Contributor Author

@hannahhoward and @vmx that sounds like a fine OKR. I'm starting to wonder how we'll figure out if a DAG smart bitswap is worth implementing? I guess we need to know how often IRL bitswap stalls after broadcasting and waits around for provider queries to complete? Or maybe how often bitswap stalls at all? I wonder if we can get this information off logs from our gateway.

I wonder if a good OKR might be to add better logging to bitswap to get better real world data off the nodes that we're running.

@magik6k
Copy link
Member

magik6k commented Dec 18, 2018

I'd like to be able to continue / focus more on CoreAPI work, mostly around implementing http client, extracting interface and creating standard tests.

Also, there is still a lot of work in CoreAPI land (in order of impact):

  • Figure out MFS integration
  • Figure out RPC backend (as discussed in London)
  • Finish other missing APIs
  • Improving docs
  • Switch all commands to use it exclusively

As for other OKRs, should we have unixfsv2 on our radar or is this more of IPLD thing?

@momack2
Copy link
Contributor

momack2 commented Dec 18, 2018

@bigs -

@momack2 would absolutely love some collaboration on the IPTB work i'm doing. particularly bringing IPTB to a clustered environment!

@hsanjuan would that be a better fit for the cluster wg or are there go-ipfs dependencies?

@hannahhoward and @vmx - agree that a solid/fleshed out graphsync spec is still outstanding, but curious if we have enough to get started on selectors in Q1 or if that's something that's on the IPLD OKRs to finalize first.

@momack2
Copy link
Contributor

momack2 commented Dec 18, 2018

High priority items from our roadmap and 2019 Project Epics that I don't see covered in the proposals so far:

  • Create testing/benchmark harness and environments
  • Tests verify that IPFS can transfer files at a relatively close speed and payload size to other File Transfer tools on the market for 1:1, and it is always faster for 1:many and many:many file transfers
  • IPFS supports <5 sec, mutable name resolution for any IPNS record
  • IPFS can efficiently add and transfer large (>1M entry) sharded indexes (objects, directories) without disabling content routing

There are also a few goals about the contributor experience (documentation, extensible interfaces, resolving in-flight refactors) that will accrue value the sooner we can allocate time to them. Do we have bandwidth to take on any of these items this quarter? Given what we're putting on our Q1 OKRs are we on track to achieve these ambitious and impressive goals?

@vmx
Copy link
Member

vmx commented Dec 18, 2018

if we have enough to get started on selectors in Q1 or if that's something that's on the IPLD OKRs to finalize first.

@momack2 I'd postpone selectors. For Graphsync proposal (C) you'd only need the "Path Selector" (the "CID Selector" really is a subset). Not sure if it's worth starting to implement the full selectors thing.

@magik6k
Copy link
Member

magik6k commented Dec 19, 2018

CoreAPI isn't really a refactor, but it may be used to eventually replace / organize a good chunk of the 'glue-code' in go-ipfs.

The main focus is providing a good external API interface which can support many backends, like directly using core.IpfsNode, using HTTP API, or mentioned RPC.

You can see it's current state in ipfs/kubo#4498.

I think something like 'Extract CoreAPI interface from go-ipfs' and 'Implement CoreAPI with HTTP backed' would be more accurate.

@momack2
Copy link
Contributor

momack2 commented Dec 19, 2018

IPFS supports <5 sec. mutable name resolution... This is an interesting one - I think this might be exclusively a libp2p effort but I'm not confident about that. @Stebalien do you know?

You're right - this is actually a Libp2p request for faster DHT, which I think is something on their roadmap (@mgoelzer and @raulk to keep me honest)

OKR/GO_CORE.md Outdated
* A work-tracking process is adopted that allows the team to easily track the highest priority unclaimed issues, see the status of in progress work, and know which PRs need review, easily.

### go-ipfs is easy to integrate
* A new flexible and performant RPC API is designed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think CoreAPI and Base32 actually fall under this objective.

OKR/GO_CORE.md Outdated Show resolved Hide resolved
OKR/GO_CORE.md Outdated
* A work-tracking process is adopted that allows the team to easily track the highest priority unclaimed issues, see the status of in progress work, and know which PRs need review, easily.

### gx becomes a beloved tool by the Go Core Contributors Travis are you still working on this?
* go-ipfs doesn't have checked-in gx paths
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Optimizing developer velocity" could be the objective. The KR would be "go-ipfs developers are no longer adversly affected by gx" (with some significant rewording). That way, either getting a maintainer or moving away from gx are valid solutions.

@Stebalien
Copy link
Member

documentation

I'd like to make this push after we get the CoreAPI in place and after we get the new RPC system. Basically, I'd like to avoid spending too much time documenting interfaces that are going to be deprecated.

extensible interfaces

In service of this:

  • Refactored IPFS constructor. @magik6k, will you likely have time to tackle this this quarter?

OKR/GO_CORE.md Outdated

### go-ipfs becomes a well maintained project
* Every non-trivial PR is first reviewed by someone other than @Stebalien.
* A work-tracking process is adopted that allows the team to easily track the highest priority unclaimed issues, see the status of in progress work, and know which PRs need review, easily.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to make this push after we get the CoreAPI in place and after we get the new RPC system. Basically, I'd like to avoid spending too much time documenting interfaces that are going to be deprecated.

@momack2 convinced me that ignoring documentation is a bad idea (ok, fine...) and suggested

  • Every file with a non-trivial change gets fully documented.

Yes, this is going to be hard, but I think that's the only way we're going to make this happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌 this allows us to improve and update our documentation incrementally as we touch/grok the code in service of our Q1 efforts. To measure this, we can pull all changed files in Q1 and check documentation coverage (and maybe spot-check documentation quality to ensure it's above par). Our goal with updating the docs is to make it easier for other contributors (new or old) to quickly onboard on modules and help move them forward.

OKR/GO_CORE.md Outdated

### Complete outstanding endeavours that are still high priorities from Q3
* base32 is supported and enabled by default
* CoreAPI refactor is completed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added the following to the spreadsheet:

  • New fuse mount implementation replaces the existing one.

@magik6k
Copy link
Member

magik6k commented Dec 19, 2018

Refactored IPFS constructor.

It really depends on how smoothly things go, I kind of wanted to leave this for Q2, and use Q1 for smaller, but related cleanups all around go-ipfs (things like ipfspath (go-path), which are used a fair bit outside go-ipfs and will very likely take time to complete (go-path is just an example, not necessarily blocking constructor refactor)).

@Stebalien
Copy link
Member

@magik6k what if we made it a P4?

Comment from @hsanjuan's presentation: we need to think about pinning. We also have fix #5221. There have been some proposed solutions (and even a few PRs), we just need to dedicate some time to evaluate them.

Not sure how to make this into an OKR.

@hannahhoward
Copy link

hannahhoward commented Dec 19, 2018

@eingenito in response to @momack2 's query I would support "a testing and benchmarking of data transfer speeds at a higher level than bitswap" OKR. We have gotten a lot of instrumentation into Bitswap actually, but after the speed improvements that are likely to be complete this quarter, we really need to move up to the level of IPFS benchmarking as a whole to measure real world transfer speeds. It's hard to know what exactly this would look like in as a repeatable, runnable test but I feel like we should explore it. I'm putting this in my retrospective which I'm of course late delivering so you don't have this information but I think it's relevant.

If I were to express this as an OKR, I'd list as something like this:
"There is a set of runnable benchmarks which can measure real world data transfer speed of the go-IPFS system as a whole against traditional file exchange tools"

I'd actually rather not get more specific cause I think figuring out what that would look like is part of the OKR. What do you think?

@eingenito
Copy link
Contributor Author

@hannahhoward

I would support "a testing and benchmarking of data transfer speeds at a higher level than bitswap" OKR

I agree . I think that would be great and it dovetails with @bigs desire to have collaboration on extending iptb

@Stebalien you probably know these OKRs from last quarter:

  • Support for complex/flexible pinning strategies (ex pinning a graph to a certain depth)
  • Transactions to blockstore support GC and pinning in parallel with adding data

We can put them in this quarter's OKRs as well. I'm trying to be spartan with our Q1 OKRs so far because we overestimated last quarter and staffing seems uncertain.

@magik6k
Copy link
Member

magik6k commented Dec 19, 2018

Refactored IPFS constructor.

what if we made it a P4?

That works for me

@Stebalien
Copy link
Member

We can put them in this quarter's OKRs as well. I'm trying to be spartan with our Q1 OKRs so far because we overestimated last quarter and staffing seems uncertain.

You're right... but cluster really needs this. I'll think about this a bit. There may be a simpler approach to unblock them.

@raulk
Copy link
Member

raulk commented Dec 20, 2018

@momack2

IPFS supports <5 sec. mutable name resolution... This is an interesting one - I think this might be exclusively a libp2p effort but I'm not confident about that. @Stebalien do you know?

You're right - this is actually a Libp2p request for faster DHT, which I think is something on their roadmap (@mgoelzer and @raulk to keep me honest)

I think so. Although depending on the solution, the pubsub subsystem might also be involved. See https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipns-pubsub.

@eingenito
Copy link
Contributor Author

eingenito commented Dec 20, 2018

You're right... but cluster really needs this. I'll think about this a bit. There may be a simpler approach to unblock them.

@Stebalien and @momack2 After talking it over with @michaelavila yesterday I'm going to add these for real and make him the owner. We sort of have to decide how far we want to take the providing work before switching focus to pinning/GC.

We're intrigued by the possibility that the provider work, if it does expand to include tracking roots, and even counting references to blocks from providing roots, might have a lot of commonality with a lockless GC implementation. And we've touched on the possibility of coupling (re)providing and pinning more closely so there might be a thing emerging there.

That's obviously not a simpler approach so by all means, it would be great if there were a quicker option. But even without one I think we'd have a good shot at getting them something in Q1.

@momack2
Copy link
Contributor

momack2 commented Jan 11, 2019

I had a long chat with @lanzafame yesterday about the cluster need for node+children pinning. Sounds like an alternate way to solve this problem for them would be to make pinning a single node much much faster - so they could make N pin calls (for each shard + the root) instead of needing a 1 layer recursive pin call to pin all shard roots from the master root. Graphsync selectors are intended to apply to both getting and pinning - so we should be careful to not to redesign a different approach.

@lanzafame, if you could partner with @michaelavila on this pin/provider management work I think it could be really useful to drive this forward while keeping all constraints in mind.

@daviddias daviddias added the P1 High: Likely tackled by core team if no one steps up label Jan 15, 2019
@momack2
Copy link
Contributor

momack2 commented Jan 15, 2019

Hello go-ipfs folks - It's time for us to finalize our OKRs for Q1 2019! Goal is to have this done by EOWeek, so let's get on it. =]

There's a quick tutorial at ipfs/roadmap#17 for a simple Roadmap timeline exercise to help us identify and reach consensus on the most important Q1 priorities. Knowing this working group, I suggest we do this asynchronously and if needed check in quickly at our next weekly meeting. As a reminder, this is how we divvied up responsibilities for drafting our 2019 Roadmap (ipfs/roadmap#4):

Everyone is also encouraged to jump in wherever they have ideas or feedback, but folks in each area should take responsibility for making sure all milestones are allocated a quarter. Once we do the exercise, we should use the "Q1" section of our roadmap as a feedback loop on whether our quarterly OKRs are putting us on the right track.

I'm available to answer questions, take part in the timeline exercise, and give feedback on iterations - so let me know if anything is unclear! I'll go do a few examples that people can improve on, but you can also look at the Project WG Roadmap for the ideal end state. =]

Some of this is already inflight, however we need an owner for benchmarking efforts
@ghost ghost assigned momack2 Feb 1, 2019
OKR/GO_CORE.md Outdated
* It takes less than 48 hours to transfer 1TB dataset over Fast Ethernet (100Mbps)
* Bitswap refactor + improvements reduce number of duplicate blocks downloaded by 75%
* Transfers of sparsely provided data are roughly as efficient as fully provided content
* Awesome go-ipfs benchmark test suite exists comparing ipfs performance and transfer size relative to bittorrent
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Awesome go-ipfs benchmark test suite exists comparing ipfs performance and transfer size relative to bittorrent
* Awesome go-ipfs benchmark test suite exists comparing ipfs performance and transfer size relative to bittorrent
* go-ipfs data transfer is thoroughly tested as part of the CI pipeline

This is in the spreadsheet right now, so adding it here for clarity

@kevina kevina removed their assignment Feb 5, 2019
@momack2
Copy link
Contributor

momack2 commented Feb 5, 2019

Hi go-ipfs team! We still have a few rows in our sheet without owners - especially a POC to help drive Base32 support over the finish line and someone to define and implement benchmarking to direct our performance improvement efforts and highlight the positive changes we make. Jump in on the sheet and volunteer before we freeze these tomorrow!

@momack2 momack2 merged commit db75d18 into master Mar 18, 2019
@ghost ghost removed the status/in-progress In progress label Mar 18, 2019
@momack2 momack2 deleted the 2019-q1-okrs-go-wg branch March 18, 2019 09:56
@daviddias daviddias mentioned this pull request Apr 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

Successfully merging this pull request may close these issues.