Document the planned import scope and order of ipfs repos

[BigLep]

Done Criteria

There is an ordered checklist/table in #202 that maintainers are aligned on and can comment on regarding:

1. What repos we'll be copying-in (and not)
2. The order that we'll do those imports
3. Expected import location

The checklist/table also includes tracking elements for each repo like:

1. Whether it has been copied in
2. Whether its issues have been reviewed and the relevant ones copied over
3. Whether the "not maintained" README notice and deprecated types have been merged.

The specific steps we'll follow for migrating each repo are also defined. This includes having agreed-upon "not maintained README messaging" that we'll put in each repo.

Why Important

Per discussion in ipfs/kubo#8543 , the adjusting of repos is disruptive for existing consumers. We want to minimize the disruption by being thoughtful and clear. (That said, originally we were actually migrating repos. Per #191 we are now copying repos, but still adding deprecation types, which shouldn't be as disruptive.)

User/Customer

1. Maintainers so we're aligned and don't have people importing repos without thinking about the bigger picture.
2. Current consumers of repos we're planning to import so they can plan accordingly or influence if we're making a mistake.

Notes

This is effectively the "roadmap" for this import effort that was kicked off in ipfs/kubo#8543.
This is the place for maintainers to be transparent and signal things like "these are the repos we're copying in and this is the status".
This will live in #202

Tasks

Beta Give feedback

1. Create an issue / doc to house the tracking checklist / table: [Tracking issue] Release for the "over the hump" copy repo consolidation #202
2. @guseggert Create the checklist / table with the list of repos that we're planning to copy in and deprecate with messaging and types (but not actually archive)
3. Include the reverting of ipfs/go-block-format in the above.
4. Draft the "not maintained README messaging"
5. Get review from @ipfs/kubo-maintainers including @BigLep
6. Surface in this issue and [Milestone] Getting boxo "over the hump" #196 so interested parties can follow along

[BigLep]

2023-02-28 maintainer conversation:
(These are chickenscratch notes that will get translated to other issues).

• Considering copying over to go-libipfs

Open questions:

1. Existing repos

• Unarchive
• Revert
• New release
  (maybe not do bitswap)

2. What do we with issues that were already migrated over? Move back?
3. What happens when there is a bug in an old repo like ipfs/go-ipfs-files?
4. Advantage of the old way: clear signal for people outside of PL
5. If not moving over but copying over, what do we do with the issues in the old repo?

Recent examples:

• Changing the fetcher API
• Finding a bug in a sub repo and not being able to handle
• Bac comments: https://filecoinproject.slack.com/archives/C02RLM3JHUY/p1677409745784779

[BigLep]

The issue description has been updated to account for the decision to copy in repos (#191 (comment) ).

[BigLep]

@guseggert has updated #202 with a proposed set of repos to copy over. This will get reviewed by @ipfs/kubo-maintainers week of 2023-03-13.

[hacdias]

After looking at the table in #202, I have some concerns about moving interface-go-ipfs-core to Kubo. I think it is a good idea, but it is a package that is all over the replace. go-libipfs imports that package for usage in the gateway code. By porting it to Kubo, we'd create a circular dependency between Kubo and go-libipfs.

interface-go-ipfs-core is only used in the gateway code, specifically:

• The horrible path mess (see Consolidate IPFS Path libraries under boxo/path #198)
• namesys options. Why do we have the options for the go-namesys library in interface-go-ipfs-core in first place, and not in go-namesys? I would move the options to go-namesys so they live with the code they are used with.
• ErrOffline - not sure what to do with this one.
• DirEntry, TFile for handling of UnixFS and stuff types. Maybe this can be removed through the gateway refactoring. Yesterday I actually suggested using our own gateway files interface because we have specific needs that are not totally met by the libipfs/files, iface or the UnixFS types themselves. /cc @lidel @aschmahmann - Protocol Labs - Lower Availability

Overall I think this one may be the most problematic. I don’t want it to live in libipfs as it is kinda specific to Kubo. However, it also contains a lot of abstractions (path , options, etc) that we use everywhere else.

So I think we should extract from the interface whatever we don’t think belongs there: path, other package’s options, etc. And then migrate it? Wdyt?

[BigLep]

Moving conversation on which repos to move where to #202

[BigLep]

Resolving this issue since the done criteria have been met. A note was also add here: #196 (comment)