Earlier quoted context omitted.
We should make an alternative git site, but how to acquire users?
Forgejo is a thing. But the headlines lately make it sound like it’s not in great shape either.
Incident with Issues and Webhooks – Resolved
231–240 of 275 posts
Re: Incident with Issues and Webhooks – Resolved
#232Earlier quoted context omitted.
It really shouldn't. The technical summary they released[1] is a very interesting read from a software engineering perspective. It seems to be blindsided by the increased traffic and gives stats related to commits/PRs (which should be relatively cheap for github to process) without any insight into their web traffic or details on how much actions are costing them. If they were super transparent they'd release informa…
> migrate their codebase to a new language[2], continue to drop their inhouse ops for Azure resources and get off MySQL The recent blog post you're linking to mentioned moving data only for webhooks off MySQL, not all relational data used by the entire site; and moving "performance or scale sensitive code out of Ruby", again not the entire codebase. Do you have an official source suggesting these migrations are more…
Re: Incident with Issues and Webhooks – Resolved
#233Earlier quoted context omitted.
I don't know why this is downvoted. The data backs you up: https://damrnelson.github.io/github-historical-uptime/
I'm skeptical about that page's accuracy. For example, if you go to the breakdown tab, it shows Actions having 100% availability when the graph starts (Apr 2016), yet Actions didn't even exist until late 2018, and wasn't GA until a full year after that. So if the math behind the "average" tab is treating NULLs as 100% uptime, this just isn't a correct measurement. The page also notes it obtains its data from the offi…
Re: Incident with Issues and Webhooks – Resolved
#234Re: Incident with Issues and Webhooks – Resolved
#235Earlier quoted context omitted.
> migrate their codebase to a new language[2], continue to drop their inhouse ops for Azure resources and get off MySQL The recent blog post you're linking to mentioned moving data only for webhooks off MySQL, not all relational data used by the entire site; and moving "performance or scale sensitive code out of Ruby", again not the entire codebase. Do you have an official source suggesting these migrations are more…
I do not know - this is the only source I'm aware of and the wording is vague enough that the above is just my interpretation of it. It could be highly targeted but the manner of wording indicates a strong preference that smells of a large migration.
"bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL)"
"Similarly, we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go" (in a paragraph specifically about "critical services like git and GitHub Actions")
Both of those sound highly targeted to me!
Re: Incident with Issues and Webhooks – Resolved
#236Earlier quoted context omitted.
I'm skeptical about that page's accuracy. For example, if you go to the breakdown tab, it shows Actions having 100% availability when the graph starts (Apr 2016), yet Actions didn't even exist until late 2018, and wasn't GA until a full year after that. So if the math behind the "average" tab is treating NULLs as 100% uptime, this just isn't a correct measurement. The page also notes it obtains its data from the offi…
I think we can agree the data is correct enough to ascribe a trend with a strong statistical significance no? Enough to draw a conclusion
You said "I can't really remember any significant downtime before the Microsoft acquisition and the data supports my memories", but my memories differ (as do other commenters), and the accuracy of the supporting data seems questionable.
Re: Incident with Issues and Webhooks – Resolved
#237Earlier quoted context omitted.
I do not know - this is the only source I'm aware of and the wording is vague enough that the above is just my interpretation of it. It could be highly targeted but the manner of wording indicates a strong preference that smells of a large migration.
What part of the wording gives you that impression? On these topics, the post literally just says the following: "bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL)" "Similarly, we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go" (in a paragraph specifically about "critical services like git and GitHub Actions") Bot…
That paragraph read, to me at least, that the initial targeted changes were just the tip of the iceberg and that much heavier lifting than initially budgeted were now in scope.
Re: Incident with Issues and Webhooks – Resolved
#238Earlier quoted context omitted.
I don't know. Everyone seems to be using GitHub only because everyone else is using GitHub. Apparently that's important somehow. Me, I use "git init"
https://en.wikipedia.org/wiki/Network_effect It's a lot easier to get bug reports and fixes when everyone is on the same auth system. That's why there is also a call for federated forges
I'm confused with auth has to do with it?
We've had OAuth 2.0 since 2012
Re: Incident with Issues and Webhooks – Resolved
#239At this point, "GH is down" posts are competing with "Newest LLM Hype" for the HN front-page week over week. For my personal project, I've been considering moving everything over to Codeberg. Stability of GH being one reason, but I also like the idea of an alternative that is not strictly tied to a big tech company.