Some issues don't show?

[jbenet]

Right now https://wking.github.io/depviz/#/http/github.com/jbenet/depviz/1 is not showing several issues, now that some are closed. I've seen some issues show when closed, so not sure what's up.

This could be an option in a future version. (we could have check boxes on the screen, etc. i'll take a stab at designing that later)

---

depends on #34

[jbenet]

Correction-- it's not the closed ones that don't show, it's some open ones. see https://github.com/jbenet/depviz/issues/1 -- it should depend on: 2, 3, 4, 5, 6

I see it as:

[jbenet]

Sorry-- i'm being dumb. 2, 3, 4, 5, 6 are all there. others are missing, may be the hop count? (eg 2 depends on 8, 9, 10, 11)

[jbenet]

[wking]

Currently we only fetch nodes that are dependencies of unfinished nodes (something like #13). If we lift that restriction (with a checkbox or some such) we'd need another way to limit expensive graph walking. Some other comments on that in #2.

[jbenet]

• I think maybe the default should be hop depth? (say 3 hops?)
• yeah agreed on making this toggles (checkbox SGTM)
• could be an "options" panel

[wking]

On Mon, Nov 28, 2016 at 11:09:11AM -0800, Juan Benet wrote:

• I think maybe the default should be hop depth? (say 3 hops?)

Hop-depth doesn't play so nicely with a draggable graph (it makes more sense if you're traversing the graph by clicking). Click-based traversing is fine, but currently the host icon links to the host and the card title links to the external issue/PR/…. We could make it the card background, but that's starting to feel a bit crowded, and triggering a re-render is expensive…

[jbenet]

• Maybe the link to the issue could be the text itself, and the card re-navigates. (already have the desire to re-center on another issue)
• :onhover could help here by adding links or something.

[jbenet]

• Also, not sure i captured it well on designs, but original intent was to show some hop-depth down to the dependents of the centered issue too (github does add issue backlinks so that data is traversable, though not 100% it's returned in API)

[wking]

On Mon, Nov 28, 2016 at 11:46:25AM -0800, Juan Benet wrote:

• Also, not sure i captured it well on designs, but original intent was to show some hop-depth down to the dependents of the centered issue too (github does add issue backlinks so that data is traversable, though not 100% it's returned in API)

I don't see it in the API 1, and even if it was there GitHub is unlikely to notice host-spanning dependents (e.g. a GitLab issue which depends on a GitHub issue). Unless we explicitly annotate these (like we do with dependencies), I expect we should not worry about them. That's not very DRY, but it does handle cross-host links.

Stepping back, I expect folks will mostly be interested in “how can I push ${OWNER}/${PROJECT} forward?”. In that case, you don't need dependents outside of that owner/project. So between the difficulty in discovery and the low utility, I'm fine punting dependent walking for now. Maybe we should spin this out into a separate issue and label it with a low priority?

[jbenet]

I explicitly want to understand:

• What are all the things this is blocking?
• Which of these issues is more important to work on first? (depends on what they block)

[jbenet]

i hear you on not tracking the external dependents, but think this will vary across hosts. i think we want to err in the side of showing the most of what we can show.

[wking]

On Mon, Nov 28, 2016 at 12:32:51PM -0800, Juan Benet wrote:

I explicitly want to understand:

• What are all the things this is blocking?

Do you really need this? If you're interested in moving github.com/ipfs forward, it doesn't really matter if they're blocking wking/some-crazy-thing/3. You're interested in figuring out if they're blocking something else in github.com/ipfs. The currently-supported user route (#7) should cover you there, although I expect performance issues if you try to view it now ;). We can address those performance issues with caching/filtering. And once we do that, I'm not sure we need additional dependent discovery.

On Mon, Nov 28, 2016 at 12:34:14PM -0800, Juan Benet wrote:

i hear you on not tracking the external dependents, but think this will vary across hosts. i think we want to err in the side of showing the most of what we can show.

I'm somewhat on board with this (I don't have a problem with showing known dependents). But I'm not excited enough about it to write something to scrape backreferences from the GitHub API, fetch the references, and scan them for dependency declarations ;).

[jbenet]

Sounds good on the above. Maybe we can make that an open issue, and link to the above. meaning:

• we want it
• it's tricky to do right (given some links will automatically backlink and some wont)
• we may have workarounds.

[jbenet]

Moved the dependents subtopic to https://github.com/jbenet/depviz/issues/25. Rest of this issue is about either traversing a number of hops, possibly click-to-re-center, possibly using :hover to show more links.