I think this should not be done in the same system as where people store their source repos. Mixing the two is convenient, but can stifle innovation. Better to have flexible and well documented abstractions and good separation of concerns.
Could you elaborate?
I think I've heard the argument before, but I don't really see how. These outages show up again and again, partly because people cannot access the project issues.
Also keep in mind that protocols are much more important than the actual code implementing them (see git for a good example!)
If I sync a git repo from random location, I have the files to make that package. However none of the documents that aren't explicitly in the git repo are provided. With Git[hub/lab/...], this is metadata outside of the repo. Ideally, I want and need that as well. If there's an issue, I can research it quickly and see if it applies to me... Or if I'm a maintainer, I can make a solution offline and then merge it when online.
I understand that it may not be the perfect tool to include everything... but it does seem to fit the bill. Fossil does seem to do this correctly. I'll have to look into it.
Fossil SCM seems to fit that bill. As another user said, they can address issues in a local, non-connected manner, and then merge the issues back to main.
The last piece would be to use IPNS so you can have the same key for a changing package. I just hope versioning support gets added in soon (it's in the spec, just not done yet with go-ipfs).