Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub issue - resolved

githubstatus.com

Post reply on HN
Print view View original

161–169 of 169 posts

Re: GitHub issue - resolved

#161

Post by harrisi »

pixl97 wrote: post #160
smcl wrote: post #82

Earlier quoted context omitted.

Step #3 is unfortunately often pointless given that often either: 1. the status page is unavailable too 2. the status page reports the service as green/available even though it's red/down (maybe it's still accessible to the service pinging its health status, maybe it's "accessible" but not actually functional, maybe the engineers were too busy fixing the problem to click the button to update the status page, maybe no…

Most places don't have an automated status page because of the issues with automation showing outages when they don't exist. Someone manually goes and clicks something on the status page.

This doesn't seem like a good reason. I can't imagine anyone checks githubstatus.com before accessing github.com. People check it after they have issues.

I assume it's more due to contracts, marketing, and denying responsibility.

Re: GitHub issue - resolved

#162

Post by fHr »

davemp wrote: post #94

Now's a good opportunity to ask about alternative Git hosts. What other services do HNers use? I've been unwilling to host any personal projects on GH after Copilot launched and it because clear that GH/MS doesn't really respect the authors of the code they host. Honestly open source in general has gotten a little less compelling to me after Copilot. The recent security issue at GH has also turned me off even more on…

Gitlab is very good and feels almost the same.

Re: GitHub issue - resolved

#163

Post by ZiiS »

bhouston wrote: post #148
ZiiS wrote: post #99

Earlier quoted context omitted.

You don't notice when their indexers cannot write; preforming a search is basically RO.

It is still a relatively complex multi-machine RO operation. It isn't like serving a static site.

Sure, but they can have several copies of the index per datacenter, retry your query multiple times posibly even in a diffrent datacenter. New code and even updated indexes can be tried and then fall back to yesterday's version.

Re: GitHub issue - resolved

#164

Post by eitland »

5mv2 wrote: post #146

Are there downtime safe GitHub alternatives?

You can always sync over local (or remote) ssh or fileshares or even zip up smaller repos, sneakernet them over to those who need them, unpack it there and pull from the unzipped folder.

The pros who maintain git uses email(!), but I think that would take more time than just waiting out the outage.

Re: GitHub issue - resolved

#165

Post by substation13 »

ZiiS wrote: post #99
bhouston wrote: post #71

Earlier quoted context omitted.

I Think he was referring to Google Search in general. I've never witness since Google went live in 1998 any Google Search downtime. Probably happened but I can not remember it.

You don't notice when their indexers cannot write; preforming a search is basically RO.

> preforming a search is basically RO

You don't know this. Google results are not the same for all users. How do you know there isn't R/W going on, particularly when signed-in to Google?

(Unless you work at Google on search, in which case I stand corrected!)

Re: GitHub issue - resolved

#166

Post by lima »

codeapprove wrote: post #149
skywhopper wrote: post #145

Earlier quoted context omitted.

Gerrit looks ugly, and the admin story is a nightmare, but it's such a better experience for code reviews (plus you can actually enforce code review in a way Github cannot). I can't stand dealing with Github for code review after spending a few years using Gerrit.

(shameless plug alert) If you're looking for a drop-in improvement to GitHub's code review experience, you may be interested in CodeApprove ( https://codeapprove.com ). It's got a lot of the things that make Gerrit appealing, but with less of a drastic workflow shift (still branch-based PRs) and a much nicer UI.

Haven't tried this one but Reviewable and Graphite. They're all very nice and yours looks nice also. The problem with all these third party SaaS-es on top of GitHub:

- You have to trust a random (no offense meant!) SaaS company with full access to your repositories, and to not disappear in a year or two.

- GitHub API rate limits end up causing issues sooner or later. For instance, Reviewable would randomly break and ask you to add more admin users so it could load balance API requests across multiple accounts!

- Likewise, you are still forced into the PR model and things that are trivial in Gerrit, like stacked diffs, are still hard. spr helps[1], but at that point you are piling workarounds on top of workarounds, might as well use a tool that supports the workflow natively...

- It gets messy unless 100% of the team is using it because then you have to somehow sync comments and approvals back and forth... And getting 100% of the team to use it isn't much easier than convincing them to use Gerrit, with all of the downsides.

[1]: https://github.com/ejoffe/spr

Re: GitHub issue - resolved

#167

Post by codeapprove »

lima wrote: post #166
codeapprove wrote: post #149

Earlier quoted context omitted.

(shameless plug alert) If you're looking for a drop-in improvement to GitHub's code review experience, you may be interested in CodeApprove ( https://codeapprove.com ). It's got a lot of the things that make Gerrit appealing, but with less of a drastic workflow shift (still branch-based PRs) and a much nicer UI.

Haven't tried this one but Reviewable and Graphite. They're all very nice and yours looks nice also. The problem with all these third party SaaS-es on top of GitHub: - You have to trust a random (no offense meant!) SaaS company with full access to your repositories, and to not disappear in a year or two. - GitHub API rate limits end up causing issues sooner or later. For instance, Reviewable would randomly break and…

All great points, and I appreciate them because I think CodeApprove's marketing materials should address them more head on.

The first two (trust with repos and GitHub API rate limits) don't really apply to CodeApprove in the same way they do to Reviewable. Because we're using GitHub's newer "apps" system and not OAuth, we only have very limited scopes (can't write code, etc.) and API rate limits go up as we get more users.

Your points about stacked diffs and PR adoption stand!

Re: GitHub issue - resolved

#168

Post by ZiiS »

substation13 wrote: post #165
ZiiS wrote: post #99

Earlier quoted context omitted.

You don't notice when their indexers cannot write; preforming a search is basically RO.

> preforming a search is basically RO You don't know this. Google results are not the same for all users. How do you know there isn't R/W going on, particularly when signed-in to Google? (Unless you work at Google on search, in which case I stand corrected!)

I am certain the are normally writes going on; they do run Analytics on their homepage. However they get to defer, retry and play lots of eventually consistent tricks, worst case just swallow the exceptions. The fact they can make the service _seem_ to the end user as fully working whilst being unable to write is a major factor in achieving their world beating reliability.

Re: GitHub issue - resolved

#169

Post by XCSme »

jonas-w wrote: post #27
larsnystrom wrote: post #19

HN should really have a “Down HN” category, as this is the most reliable place to get this information.

Everytime something has degraded performance or is down for me: 1. check my internet connection 2. check HN 3. check official statuspage

> check my internet connection

How do you do that?

Post reply on HN