Copied or Migrated Repos FAQ
The FAQs below concern all the repos that were copied or migrated into boxo to bootstrap the library in 2023Q1. Some of the repos are copies of repos that are maintained by others, but most of the repos that were copied are now not maintained.
See here.
The authoritative list is in https://github.com/ipfs/boxo/blob/main/cmd/migrate/internal/config.go. Many of these were handled as part of https://github.com/ipfs/boxo/issues/202.
What will happen if there is a security issue in one of the legacy ipfs/* repos that has been copied into boxo?
@ipfs/kubo-maintainers (which primarily maps to PL EngRes IPFS Stewards as of 202203) will certainly handle patching boxo. If there are maintainers for the original/source repos, they will need to handle patching/disclosing. @ipfs/kubo-maintainers will certainly coordinate and share work, but they won't handle communication with or updating of the affected consumers of the original repos that boxo copied from. If there are no maintainers for the original/source repos, there will likely be internal/private PL EngRes chats analyzing which projects are impacted, and it will then be up to those projects to determine whether they want to patch the existing repos or update to use boxo. (We understand and expect that the "update to boxo" option will often not be possible under tight timelines given boxo's plans to upgrade its dependencies frequently and refactor the existing code.)
How does Boxo make sure it doesn't miss any important changes that are in the original/source/copied repos?
A mechanism for this is being tracked here: https://github.com/ipfs/boxo/issues/270
I don't like the "deprecated" warnings in "not maintained" repos that have been moved to boxo. What can be done about this?
The intent of the "deprecated" warnings was to be clear to consumers about the status of the repo: that it isn't maintained and that there is a repo where similar code is being maintained. If another maintainer comes along, then they can claim ownership and the state of the repo can be adjusted. This satisfies the requirement about being clear to users about who owns a repo and its status.
Many of the existing issues and PRs have been open for years. If they hadn't been completed by this point, it seems unlikely that they would be now without fresh signal that the issue is still truly important and blocking someone. In an effort to avoid noise and crippling in the Boxo repo from the weight of issues of the past, we elected to let motivated parties open a new issue in Boxo if something was truly important.
A new maintainer can
- create a PR that includes:
- Revert of the deprecation types
- Removal of the "not maintained" notice from the README
- Addition of themselves to CODEOWNERS
- Get @ipfs/kubo-maintainers attention by @mentioning them in the PR and/or posting in the venue(s) discussed in https://github.com/ipfs/boxo#help
Assuming the new maintainer is known/trusted, @ipfs/kubo-maintainers will merge.
PL EngRes @ipfs/kubo-maintainers don't want to leave a wasteland of unmaintained repos. We'll come back through and archive repos that haven't had a maintainer step up in sometime 2023Q3. See https://github.com/ipfs/boxo/issues/201.
Yes. We didn't just copy in the files but preserved the git history. This work was tracked in https://github.com/ipfs/boxo/issues/202 and https://github.com/guseggert/repo-migration-tools was used.
- Issues that spawned generating this document: https://github.com/ipfs/boxo/issues/190 and https://github.com/ipfs/boxo/issues/196