191–200 of 253 posts
Githubs uptime is pretty bad. Isn't it under 95% for the year now?
Not really. It is just very public when they go out. Steam, Blizzard, Activation are down at least 6 hours a week. While Bank of America is offline 24hours/month. Scheduled downtime is still downtime.
Except in the SLA.
I've argued more than once when watching a vendor announce "emergency scheduled maintenance"(!) as an outage is looming.
I saw a comment earlier mentioning that GitHub allegedly doesn't release post mortems publicly? If this is true, that's upsetting.
Earlier quoted context omitted.
#1 can be done by creating a separate submodule repo that only stores docs+issues files. It's up to the repo's users to agree on a system by which the files should be organized, but it's doable. I'd propose directories "issues/open", "issues/closed", with each issue filename being "{created:yyyy-MM-dd} - {subject}.md". Symlinks could be used to track ownership/responsibility if each repo contributor has their own dir…
That's an awful lot of extra work to insure against maybe 1 hour per year of downtime.
You back up your data, why shouldn't you backup your github data?
If anyone is interested, I've been working with a git host that is actually distributed across a p2p network using SSB. see: https://github.com/clehner/git-ssb https://github.com/noffle/git-ssb-intro It's been working fairly well so far. We are using git-ssb to manage a few projects instead of putting them into Github.
Earlier quoted context omitted.
> if they could find away to make Git only work with Github they would in a heart bet. Sorry, but this is unfair :) I remember the early days of Gitlab, before they added all the insanely cool features they have now, when they were just a Github opensource copycat. My thought at the time was : "wow, github is super cool to let them go. At least the almost exact design copy could be a legal problem". Clearly, we would…
Well, if we "heard about GitHub vs. Gitlab" more people outside HN might hear about GitLab. Might be more dangerous, than the chances of a win shutting GitLab down.
Earlier quoted context omitted.
That's an awful lot of extra work to insure against maybe 1 hour per year of downtime.
Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github data?
Earlier quoted context omitted.
You're sidestepping the main reason I believe it worked so well. It benefits from network effect. It is a collaborative tool and people like to have their work on there so others can collaborate with them.
That's important but I think people over-estimate it. It's both. I predict that if you analyzed the github network, you'd find many hubs are based around companies that chose to move their workflows to github based on features other than network effects. Or at least, the existing network was only one of many reasons.
Earlier quoted context omitted.
I'm of the impression that issues and PRs are all accessible via an API. What more should they do?
> What more should they do? How about storing issues and PRs in the actual git repository? They should index them for the UI, sure, but the source of truth should be a branch of the git repo just like it is with gh-pages. It should be possible to file a new issue by committing a markdown file to the correct branch and pushing it to Github. Their hub command line tool and their own client could facilitate adding all t…
Access to the git repository is regulated; issues and PRs aren’t. Anybody can fill an issue/PR on your repo, but only you (and your team) can modify the repo. You’d need to also store all the comments on all issues and PRs, even closed/rejected ones. In some repositories, that’d be huge.
Earlier quoted context omitted.
Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github data?
Backup is one thing, choosing to run a crappy manual system just in case a vendor goes down is entirely different.
Hmm, I think I might be on to something... anyone want to start a project?
Earlier quoted context omitted.
> Maintner is short for "Maintainer"...the name of the daemon that serves the maintner data to other tools is "maintnerd". Nice work! But as is custom on HN, I'll bikeshed on the name instead of delving into the contents of the tool. Why shorten the word by just 2 letters? Is there something special about the tooling that makes 8-letter projects more desirable than 10-letter projects, or is it linked to the removal o…
I'd prefer it just for searchability. Good luck finding anything online called "maintainer".