Live data from Hacker News

GitHub Outage Currently Ongoing – Issues, PRs, Notifications

githubstatus.com

91–100 of 106 posts

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#91

Earlier quoted context omitted.

Seriously though this summer has been unusually bad ceteris paribus right? We need a State of the SaaS address.

Give us some credit: it's the best 2019 we've had so far!

2019 BC doesn't even have a Wikipedia page!

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#92

I kind of wish HN wouldn't show these outages unless they're going on for multiple hours or at least hide them after they're back up. Usually by the time I see them and then check myself the site is already back up. Maybe I just need to read HN more often.

> Maybe I just need to read HN more often.

Last night I wrote a little spreadsheet for myself showing how much time I spend doing various things. In particular, I for one do NOT need to read HN more often

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#93

Earlier quoted context omitted.

True, but this is not a link to a post-mortem, it's just the status page.

Maybe publicizing these outages is the main reason the post-mortems are made available.

That seems at least partially true. However, I suspect that people would continue to think highly of tech companies that posted post-mortems, even if the issues were hitherto unknown. Ie, maybe it isn't only an act to prove that 'we are still trustworthy and transparent,' but also somewhat positive in and of itself?

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#95
post #77

Alright, cue the usual: Monoculture bad Microsoft bad Git is distributed but all the things around it that we really need aren't You can set up git to push to multiple remotes automatically Nobody is actually using git in distributed mode Did I forget anything?

> Git is distributed but all the things around it that we really need aren't Can anyone recommend an issue tracker that is distributed with the repo?

I'm building one: https://github.com/MichaelMure/git-bug

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#97

Everyone needs more sex. End of discussion. Who cares about github

If people trucked more, nothing would be a problem. Nothing would look like a nail or a hammer. Truck it up. Truck github. You trucking beanbag cellar pieces of grits. Trucking makes the world go around. <3

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#98

Alright, cue the usual: Monoculture bad Microsoft bad Git is distributed but all the things around it that we really need aren't You can set up git to push to multiple remotes automatically Nobody is actually using git in distributed mode Did I forget anything?

Publicly visible outages on "pro" internet properties are actually a good thing because they help correct the views so commonly held by low-information executives about 5-nines and uptime. The more ammo people have, in aggregate, that "XXX never goes down" is a lie, the better off we will be as an industry.

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#99
post #77

Alright, cue the usual: Monoculture bad Microsoft bad Git is distributed but all the things around it that we really need aren't You can set up git to push to multiple remotes automatically Nobody is actually using git in distributed mode Did I forget anything?

> Git is distributed but all the things around it that we really need aren't Can anyone recommend an issue tracker that is distributed with the repo?

A commited todo.txt [1] file with project.

[1]: todotxt.org

Re: GitHub Outage Currently Ongoing – Issues, PRs, Notifications

#100
post #83

Earlier quoted context omitted.

@TODO comments strewn around in your repo.

I was thinking of something that wouldn't be affected by the git history. There's no point in having branches for issue comments. Something like: $ git issue add "foo doesn't work" Created issue ece5591: foo doesn't work $ git issue comment ece5591 "the problem might be with bar" Created comment 0191fa1 on issue #10. $ git issue comment --reply 0191fa1 "or with baz" Created comment f98e783 on issue #10. $ git issue s…

The nice idea to having issues in your history/branches is that it easily inverts the "flow" of branch state information: most issue trackers do a lot of work to figure which changes affect which issues, and which branches those changes are in. This often requires a lot of explicit manual work like making commit notes always include issue numbers for instance and "magic" commands like "Resolves #10" to auto-close issues.

If the issues are just another source artifact alongside the code in the same git history a lot of that information flows the other direction. Instead of a magic command in a commit note to close an issue, an issue closing shows up in a diff in the commit. Figuring out which issues are still open in a given branch (what isn't in our release branch yet?) is a simple command in a branch. Figuring out which issues changed between branches (what's finished in this feature branch that hasn't been merged to release yet?) is a typical diff operation.

In terms of documenting the state and progress of an individual branch in a complex project there can be a lot of magic in having issues tracked directly inside code branches. It's a fascinating ideal for code documentation to have issue comments, changes, and workflows side-by-side the code that changed with it.

That said, issue trackers are sadly not ideal code artifacts for a lot of reasons, including that it is easy to forget that issues aren't just for coders, but also stakeholders/product owners/PMs/etc.

Post reply on HN