41–50 of 119 posts
Earlier quoted context omitted.
Average 50 percent active (as in daily usage)? 2 hours lost? I'd estimate a couple of order of magnitudes less...
I don't think 2 hours is an exaggeration for an active user. The 50% might be too high, I agree.
Average lost I'd guess to 10 minutes (most of it being "huh, wonder what's up with github")
https://gitlab.com/explore/projects is a live feed of project activity, suitable for code surfing. It also sorts by stars and trending.
I don't understand why code hosting platforms like GitHub, GitLab or BitBucket have so many issues regularly. Is there anything special about it?
Define regularly. I can recall only 2 incidents this year. I think that's not too bad considering the level of traffic they have to contend with.
Still not bad, but 2 incidents like this a year, is usually considered unacceptable for infrastructure service providers.
Lets do a quick back of the envelope calculation: Github reports 28,337,706 users by 2018-06-05 [1]. Lets assume 50% of these are active. Lets also assume that, due to the unavailability of GH, around 2 usable hours per developer are lost. Another assumption is that each developer contributes around 50 US$ per hour. This means, this outage has cost us users: (28337706 * .5 * 2 * 50) = 1.351 billion US$. Perhaps not u…
Earlier quoted context omitted.
Define regularly. I can recall only 2 incidents this year. I think that's not too bad considering the level of traffic they have to contend with.
Considering this is going on for several hours now, their SLA is down to at least 99.9 and going down by the hour. Their business SLA is 99.95% (though I have no idea what it refers to), so it's quite possible that they are in breach. Still not bad, but 2 incidents like this a year, is usually considered unacceptable for infrastructure service providers.
Earlier quoted context omitted.
Lots of users. Also, a lot of package managers rely on hosting platforms like GitHub to host their packages, so if Github breaks, a lot of CI processes around the world break.
Which is kind of ridiculous. If your CI breaks because GitHub is down, it means it's not caching dependencies locally, but keeps re-downloading them every time it runs (e.g. every commit), generating tons of waste and unnecessary load on the hosting service. Or, to put it bluntly, if your CI works like this, it's contributing to climate change.
Don't try creating a new repo, it will create part of the meta data but not allow you to see or use the repo and the repo name gets taken.
However, it's still intermittently failing as of 14 UTC, so I haven't managed a Maven release build yet.
It seems very unwise to have essentially your whole deployment process manager in the hands of an entity which you don't only have no control over, but which has regularly been targeted in attacks by nation-state-level actors because of their role as a code hosting platform.
EDIT: GH hasn't been targeted regularly, but it has been so historically, so this is a plausible thing which might happen again.
Earlier quoted context omitted.
Define regularly. I can recall only 2 incidents this year. I think that's not too bad considering the level of traffic they have to contend with.
> Define regularly More often than what is considered a standard 99.99% uptime SLA? (about an hour per year.) You seem to be making it out like a couple of days a year of lost [1] developer productivity is no big deal. That said, these things happen and you should probably check your workflows if you're all that blocked by GitHub being down.
GitHub SLA is 99.95% and apparently exclusive to Business Cloud customers[1].