5 ms·

> Github is a platform that should not need a particularly high uptime from the point of view of any one user. This is totally false. GitHub doesn't just prov

> Github is a platform that should not need a particularly high uptime from the point of view of any one user. This is totally false. GitHub doesn't just provide a git server, it also provides ticketing and project management. When GitHub is down, projects that rely heavily on, for example, commenting on issues grind to a halt. Yes, you don't need GitHub to be up 99.999% of the time to do a `git push` every once in a while, but there are other projects that use other features of GitHub besides the git server aspect.

tenfingers 11y ago
And it's a shame this is the case, though. I do publish projects with github because of the popularity of the platform, but I really don't approve github pull requests, and I also don't like github over-simplified issues. Together, these two features are probably what most projects depend on. Github pull requests are definitely inferior to the patch-by-mail approach for a conversation within a closed group of people. It's clicky and looks friendly, but you don't have the patch to see in the mail notification (you have to be online), and again it's more convoluted to edit/apply using vanilla git. Many people don't know, but git makes patch-by-mail handling extremely convenient to handle. In fact, it's more convenient to handle than using the several github command-line interfaces I tried(!). You submit the patch, have a conversation by regular mail, and then either edit the patch or merge it. Everything is always right there. Using github you have several side effects: people often add comments to specific lines in the patch, which will looks like garbage in the generated github notification. People will also naturally edit the comments, which won't generate notifications. I cannot count how many times I have to re-read comments because I had the feeling I missed something (and indeed, some comments were edited). This is bad. It shouldn't be allowed. It cannot happen with email. Github has the advantage of making the conversation visible. But if you have a developer mailing list for your project, git and plain, regular patches do work really well. It might take a bit more to get used to, but it pays back. Issues are a different problem, since I still feel the distributed solutions are inferior. I experimented a lot with bugs-everywhere and simple defects (sd), two distributed bug trackers that store the issues in the repository itself. Both are nice, and have distinctive features from each other which I'm not going to discuss much. The main thing is that 'sd', at some point, even supported to sync issues with github, which allowed to have best of both worlds. Unfortunately, it's lacking maintenance at the time, but it would solve ticketing in a distributed way. It looks like there's not much interest in this, as both projects are definitely not as active as the many available github clients which do 1/10 of what these projects offer. Please, look into these two projects.
- coherentpony 11y ago
  Thanks for the distributed issue tracker mentions; I didn't know they existed.
Zikes 11y ago
It's also the primary host for dozens of package management systems anymore. It's not hard to imagine a production system being unable to scale out because they didn't vendor and they can't fetch the repo for an essential library.
brudgers 11y ago
I see your point about productivity. From a CAP perspective the ticketing and other project management processes depend on all three.
thom_nic 11y ago
It also acts as the de-facto authentication provider for a ton of third-party hosted services. I don't know if "login with github" stopped working during this outage but I can imagine the sort of hell if I suddenly couldn't access my PaaS running production infrastructure because it couldn't authenticate my github account.
k_bx 11y ago
Our Jenkins is configured to sign-in with GitHub. And yeah, it sucked to not be able to get in. Probably in future it's best to move away to non-Gihub accounts.
abhishekghosh 11y ago
Agreed with you. There are gists which people curl or wget from the servers. Github is not exactly like source forge or something like that....
- stephenr 11y ago
  Sounds like a poor choice if you're curling scripts from GitHub

tenfingers 11y ago

And it's a shame this is the case, though. I do publish projects with github because of the popularity of the platform, but I really don't approve github pull requests, and I also don't like github over-simplified issues. Together, these two features are probably what most projects depend on. Github pull requests are definitely inferior to the patch-by-mail approach for a conversation within a closed group of people. It's clicky and looks friendly, but you don't have the patch to see in the mail notification (you have to be online), and again it's more convoluted to edit/apply using vanilla git. Many people don't know, but git makes patch-by-mail handling extremely convenient to handle. In fact, it's more convenient to handle than using the several github command-line interfaces I tried(!). You submit the patch, have a conversation by regular mail, and then either edit the patch or merge it. Everything is always right there. Using github you have several side effects: people often add comments to specific lines in the patch, which will looks like garbage in the generated github notification. People will also naturally edit the comments, which won't generate notifications. I cannot count how many times I have to re-read comments because I had the feeling I missed something (and indeed, some comments were edited). This is bad. It shouldn't be allowed. It cannot happen with email. Github has the advantage of making the conversation visible. But if you have a developer mailing list for your project, git and plain, regular patches do work really well. It might take a bit more to get used to, but it pays back. Issues are a different problem, since I still feel the distributed solutions are inferior. I experimented a lot with bugs-everywhere and simple defects (sd), two distributed bug trackers that store the issues in the repository itself. Both are nice, and have distinctive features from each other which I'm not going to discuss much. The main thing is that 'sd', at some point, even supported to sync issues with github, which allowed to have best of both worlds. Unfortunately, it's lacking maintenance at the time, but it would solve ticketing in a distributed way. It looks like there's not much interest in this, as both projects are definitely not as active as the many available github clients which do 1/10 of what these projects offer. Please, look into these two projects.

coherentpony 11y ago
Thanks for the distributed issue tracker mentions; I didn't know they existed.

Zikes 11y ago

It's also the primary host for dozens of package management systems anymore. It's not hard to imagine a production system being unable to scale out because they didn't vendor and they can't fetch the repo for an essential library.

brudgers 11y ago

I see your point about productivity. From a CAP perspective the ticketing and other project management processes depend on all three.

thom_nic 11y ago

It also acts as the de-facto authentication provider for a ton of third-party hosted services. I don't know if "login with github" stopped working during this outage but I can imagine the sort of hell if I suddenly couldn't access my PaaS running production infrastructure because it couldn't authenticate my github account.

k_bx 11y ago

Our Jenkins is configured to sign-in with GitHub. And yeah, it sucked to not be able to get in. Probably in future it's best to move away to non-Gihub accounts.

abhishekghosh 11y ago

Agreed with you. There are gists which people curl or wget from the servers. Github is not exactly like source forge or something like that....

stephenr 11y ago
Sounds like a poor choice if you're curling scripts from GitHub