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

2018 Q4 OKRs Planning #1566

Merged
merged 4 commits into from
Sep 28, 2018
Merged

2018 Q4 OKRs Planning #1566

merged 4 commits into from
Sep 28, 2018

Conversation

daviddias
Copy link
Member

@daviddias daviddias commented Sep 15, 2018

@daviddias
Copy link
Member Author

daviddias commented Sep 21, 2018

Here goes my first suggestions:

  • js-ipfs needs to be capable of handling transferring a dataset such as ImageNet (large shareded directory) and not more far than one order of magnitude from go-ipfs performance
  • npm-on-ipfs becomes the default registry that we as IPFS devs use to install npm dependencies
  • Performance and Stability harness is built. We get tests with 50000 nodes.

@daviddias
Copy link
Member Author

I've captured notes from the Retrospective and delivered them as feedback and proposed OKRs for the DX team -- ipfs-inactive/dev-team-enablement#142.

@daviddias
Copy link
Member Author

I've also captured the notes from the Weekly Discussions and Retrospectives and communicated to the @ipfs/infrastructure Team our proposed OKRs at ipfs/infra#434

@daviddias
Copy link
Member Author

daviddias commented Sep 22, 2018

More proposals:

  • The Awesome DHT Endeavour is landed - Awesome Endeavour: DHT Part II #856, there fore completing the last milestone of Connectivity Magic
  • Base32 CID Migration is complete
  • Onboard 3 new contributors

@daviddias
Copy link
Member Author

Another one:

@achingbrain
Copy link
Member

I want to:

  1. Get everyone on npm-on-ipfs. This will involve at least:
    1. Shoring up the hosting situation
    2. Having CI use it
    3. ipnpm install or similar
  2. Decompose js-ipfs-unixfs-engine into smaller modules
  3. Bottom out unixfs-v2
  4. Decompose js-ipfs into smaller modules similar to the approach taken with js-ipfs-mfs

I'd also like to see opt-in continuous deployment for JS projects. E.g. you merge a PR, Jenkins builds it, revs the version number and publishes a new version to npm or deploys an app, etc.

@hugomrdias
Copy link
Member

The main topics/areas i think we should improve are:

  • error handling, build upon the work Alan/Jacob already did with err-code plus i think we can define static error codes in a file and export them for use just like node does.
  • cli level up, continue the work in this PR feat: improved error handling on the CLI #1335, simplify the flow, add more features in line with go impl
  • add logging and error tracking (ex. https://sentry.io) for long running js nodes
  • improve tests, remove duplication (ipfs-api, ipfs, ctl, interface all test the same code multiple times), cli tests can use yargs.parse instead of actually spawning processes
  • make ipfs and ipfs-api smaller and easier to bundle and uglify
  • optimise hot code paths (get/cat/add) in line with my big data work and David suggestions above Perf Profilling and js-ipfs needs to be capable of handling transferring a dataset such as ImageNet (large shareded directory) and not more far than one order of magnitude from go-ipfs performance, i have a lot of half done work on this i would like to finish. This should focus on simplifying code, benchmark alternative implementations of key components, profile/debug bottlenecks on mem and cpu (but mostly mem for now, better to be slow than crash)
  • improve service worker DX and features ref. https://github.com/ipfs/developer-meetings/blob/master/sessions/deep-dive/service-worker.md
  • make more issues like this A viable alternative to go-ipfs? #1563 and to get feedback from what ppl really need from the js impl. Implement this A viable alternative to go-ipfs? #1563 (comment) would be cool :)

@alanshaw
Copy link
Member

  • npm-on-ipfs becomes the default registry that we as IPFS devs use to install npm dependencies

ha, done. I've been using it for weeks now!

Seriously though, +1 on this, and using it on CI.

@alanshaw
Copy link
Member

alanshaw commented Sep 24, 2018

Personally I need to focus on completing the work I started last quarter:

  • Complete CIDv1 base32 work
  • Setup and run a js-ipfs daemon on the wider internet & address any further crashes

It's super important that CIDv1 base32 becomes a thing from a security perspective for the gateways, but also...TODO

In the retrospective for Q3 I listed this:

  • Get metrics for slow test improvements

I've made progress on speeding up JS IPFS in Q3 (ipld/js-ipld#145, #1528, #1542, ipfs-inactive/dev-team-enablement#73), but there's not just one thing that contributes to slowness. I think rather than gathering stats on this particular round of improvements, time would be better spent identifying some useful benchmarks and creating a re-usable harness that can be run against js-ipfs to track and graph performance over time.

We should also be able to run these for older releases and compare and contrast with the same benchmarks in go-ipfs. Maybe iptb is the thing to use for this?

The biggest thing I see as a hurdle to js-ipfs being a viable alternative to go-ipfs is not having a DHT. This is the last step of our connectivity magic plan, and I think that it'll enable people to seriously use js-ipfs (outside of a browser context) as a serious alternative to go-ipfs.

@daviddias
Copy link
Member Author

@alanshaw, @hugomrdias and @achingbrain, wanna take a stab of converting the KRs proposed in this doc into a commit to the OKR file so that we can then evaluate together? Following of how we've done this in the past and how js-libp2p continued the tradition.

@alanshaw
Copy link
Member

@diasdavid @hugomrdias @achingbrain I've added a first pass attempt, please let me know what you think 😄

OKR.md Outdated
* P0 - @hugomrdias - JS IPFS is capable of transferring a large dataset like ImageNet at least 75% as fast as Go IPFS
* P2 - @hugomrdias - The browser bundle of IPFS is not more than 1.5MB (gzipped) in size
* P3 - @hugomrdias - Browser bundle size is measured over time and developers alerted if it increases above 1.5MB
* P1 - @alanshaw - A website is published to visually track a set of basic performance profiles of JS IPFS releases over historical versions
Copy link
Member Author

Choose a reason for hiding this comment

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

Could it be continuing the work of https://github.com/ipfs/benchmark.js.ipfs.io?

Copy link
Member

Choose a reason for hiding this comment

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

I will certainly be looking at how it can be used/extended!

OKR.md Outdated

* P0 - @hugomrdias - Error codes are added to all errors that originate directly from JS IPFS
* P2 - @alanshaw - Test quality is improved, duplicates removed and coverage increased
* P0 - @achingbrain - js-ipfs-unixfs-engine is decomposed into smaller modules for better maintainability, testability and reliability. The refactored modules are part of a JS IPFS release
Copy link
Member Author

Choose a reason for hiding this comment

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

Make sure to extract the HAMT so that it can be used as a generic KV store on top of IPLD //cc @mikeal

OKR.md Outdated
# Stable and future proof

* P0 - @hugomrdias - Error codes are added to all errors that originate directly from JS IPFS
* P2 - @alanshaw - Test quality is improved, duplicates removed and coverage increased
Copy link
Member Author

Choose a reason for hiding this comment

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

Over the entire project? Better take a snapshot then :)

Copy link
Member Author

Choose a reason for hiding this comment

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

image

Copy link
Member Author

@daviddias daviddias left a comment

Choose a reason for hiding this comment

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

👏🏽👏🏽👏🏽

I like these!

OKR.md Outdated
* P2 - @alanshaw - Test quality is improved, duplicates removed and coverage increased
* P0 - @achingbrain - js-ipfs-unixfs-engine is decomposed into smaller modules for better maintainability, testability and reliability. The refactored modules are part of a JS IPFS release
* P2 - @achingbrain - Candidate modules for extraction from JS IPFS (e.g. js-ipfs-mfs) are identified and agreed
* P1 - @achingbrain - Continuous deployment is an option for all Protocol Labs JS projects. 3 IPFS/IPLD/libp2p projects are setup to be continuously deployed
Copy link

Choose a reason for hiding this comment

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

an helpful deliverable on this would be deploy requirement docs for each project to help during CD implementation.

OKR.md Outdated
* P0 - @vasco-santos - DHT is enabled by default and interoperates with Go IPFS DHT
* P1 - @vasco-santos - IPNS is functional over pubsub and the DHT
* P0 - @alanshaw - Base32 CIDv1 migration is complete
* P0 - @alanshaw - A JS IPFS daemon is part of the IPFS gateways
Copy link

Choose a reason for hiding this comment

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

what does "is part of" mean here?

Copy link
Member

Choose a reason for hiding this comment

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

I mean that it is one (or more!) of the nodes that belong to the IPFS gateway.

Obvisously this will require close communication with the infra team and I anticipate working on requirements the infra team may have for an IPFS gateway node (setup?, reporting?, throughput?, stability?). I'm thinking we'll likely want to "soft" launch and gradually ramp up traffic being directed to the node as performance and stability are proven.

@vasco-santos
Copy link
Member

@alanshaw it would be nice to have a repo migration tool. What do you think?

@alanshaw
Copy link
Member

@vasco-santos thanks for raising this - yes we really need that, we spoke offline and it looks like your time constraints won't allow you to get to it this quarter. I think we might have to bump it to next quarter unless @achingbrain or @hugomrdias feel they can also fit this in!?

@achingbrain
Copy link
Member

I could take that on, would love to get a bit deeper into the repo

@achingbrain
Copy link
Member

Maybe drop the unixfs-v2 thing from my OKRs - there's this already: ipld/legacy-unixfs-v2#12 and @mikeal seems to be pushing ahead with that.

@alanshaw
Copy link
Member

@achingbrain it would be beneficial for the unixfsv2 spec to have been reviewed, and possibly had input from someone who has intimate knowledge of v1. You built the JS MFS implementation and are the lead maintainer for js-ipfs-unixfs-engine. I can't think of someone more qualified to do that from the JS team 😄

It sounds like @mikeal has the same goal to have a draft ready by the end of Q4 - it would be awesome if you could help him pull it over the line?

@alanshaw
Copy link
Member

@diasdavid @achingbrain @hugomrdias @vasco-santos I'm going to transfer these to the spreadsheet now as it looks like we're nearly done 😱. Please double check the latest changes here 🚀 🚢 👍 😃

@alanshaw alanshaw merged commit 2d7cfc5 into master Sep 28, 2018
@ghost ghost removed the status/in-progress In progress label Sep 28, 2018
@alanshaw alanshaw deleted the 2018-Q4-OKRs branch September 28, 2018 14:31
* P2 - @achingbrain - Candidate modules for extraction from JS IPFS (e.g. js-ipfs-mfs) are identified and agreed
* P1 - @achingbrain - Continuous deployment requirements for infra are established making CD an option for all PL JS projects. 3 IPFS/IPLD/libp2p projects are setup to be continuously deployed
* P2 - @achingbrain - A draft spec for unixfs-v2 is finalized
Find the **js-ipfs OKRs** for 2018 Q4 at the [2018 Q4 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/d/139lROP7-Ee4M4S7A_IO4iIgSgugYm7dct620LYnalII/edit#gid=274358435)
Copy link
Member Author

Choose a reason for hiding this comment

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

⚡️👏🏽👍🏽

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants