I mean, internal CI and version control systems go down too. Like, if GitHub has substantially worse downtime than an whatever internal system one runs, fair enough.
Git’s distributed, so downtime isn’t usually a huge deal compared to a non-distributed version control system.
I think that the largest issue is actually that GitHub provides a centralized commit review system (and, to be fair, so are many internal systems) that one uses to review pull requests. Like, a CI run being deferred usually isn’t a huge deal. Version control is probably distributed these days. But code review is something that you’d like to keep going.
If you do code review in email or something, it’s distributed. You can keep working. If your email server goes down, it might prevent new messages from reaching other users, but all of the review requests you have can be worked on and any review you’ve already received can be read. But if people are using some centralized Web-based code review system, and that goes down, then that kinda halts a lot of stuff.
Same centralized problem for issue tracking.
EDIT: I’ve never used a distributed issue tracker, but apparently they are indeed out there:
EDIT2: A lot of issue trackers involve people attaching large files to issues, so there might be some fundamental scalability issues in that regard for distributed operation; might need to centralize that part. That being said, I’d rather temporarily lose access to just a large-file-hosting server than to that and all of the other issue data.
It looks like it supports bridging to GitHub and a number of other issue trackers, so while the project is using GitHub’s issue tracker, I’d bet that the devs are using their own system to interface with it.
I mean, internal CI and version control systems go down too. Like, if GitHub has substantially worse downtime than an whatever internal system one runs, fair enough.
Git’s distributed, so downtime isn’t usually a huge deal compared to a non-distributed version control system.
I think that the largest issue is actually that GitHub provides a centralized commit review system (and, to be fair, so are many internal systems) that one uses to review pull requests. Like, a CI run being deferred usually isn’t a huge deal. Version control is probably distributed these days. But code review is something that you’d like to keep going.
If you do code review in email or something, it’s distributed. You can keep working. If your email server goes down, it might prevent new messages from reaching other users, but all of the review requests you have can be worked on and any review you’ve already received can be read. But if people are using some centralized Web-based code review system, and that goes down, then that kinda halts a lot of stuff.
Same centralized problem for issue tracking.
EDIT: I’ve never used a distributed issue tracker, but apparently they are indeed out there:
https://github.com/git-bug/git-bug
EDIT2: A lot of issue trackers involve people attaching large files to issues, so there might be some fundamental scalability issues in that regard for distributed operation; might need to centralize that part. That being said, I’d rather temporarily lose access to just a large-file-hosting server than to that and all of the other issue data.
Ironically, on Github
It looks like it supports bridging to GitHub and a number of other issue trackers, so while the project is using GitHub’s issue tracker, I’d bet that the devs are using their own system to interface with it.