Haha, reminds me off bringing down office mail servers by accidentally creating loops of emails back in the day... What is old is new again, but this time with probabilities :)
What is the quality-first, high uptime alternative to GitHub? My employer uses both GitHub and GitLab, and while I think GitLab is better, its quality also frankly sucks. It's riddled with bugs that have just been marinating on the issue tracker for years, and the most common "fix" for gnarly bugs in the CI platform is "revise the documentation to reflect the existing (broken) behavior".
Your favorite search engine or LLM will show you in a second, it's really easy.
The problem is that it's not enough. The fact that Github uses Git specifically is a technical detail; it could use mercurial equally easily, as Bitbucket used to. Github Actions, OWNERS files, PRs and review tools, issue tracker, wiki are all not Git features.
True, workers can still commit to their local git.
I've been looking into having a separate git server that we can commit to and add plain ole git hooks to, and just having it be synced with github as a clone.
I mean, there are solutions, but none of them seems to have a large enough mindshare and efficiency. (Even though Github's code review tools are pretty spartan.)
They can be. A PR can be made and code review conducted by submitting a patch to a mailing list. That's how the kernel and, I think, git itself is developed.
CI/CD is really a methodology. It just means integrating/deploying stuff as soon as its ready. So you just need maintainers to be able to run the test suite and deploy, which seems like a really basic thing.
If GH has an issue, it seems to always be around 4pm or 5pm GMT. I'm starting to think that i should avoid any planned production releases around this time.
I did this in 2019, it avoided so many headaches. CI is better too since there's a nice clean mapping of build -> pod for everything and I can just exec in if something's borked.
It's not as bad as you think, I run the helm upgrade when patches come out, the backing store is S3 or managed SQL, it runs a nightly k8s cron called gitlab-backup which tarballs the whole thing into an s3 bucket with a single command restore should disaster strike. (This is part of the product, not a thing I wrote.)
I probably only babysit it for 30 minutes per year, including all the upgrades.
^ this. the last thing i want is to add to my workload. take my money and make my life easier, even if it means that for one hour every couple months i can't do anything
It depends how high you value your headaches, and how high, your org's downtime. Github not working accrues over the hourly rate of every developer affected, which is likely $70-$100 a hour. 10 hours of outage in a year affecting a team of 10 would cost north of $70k, enough to hire a part-time SRE dedicated just to tend to your Gitlab installation.
We did hire some, boss! Soshie, Vizzy and Dexter. They're AI, but they're supposed to be way better than a human SRE. At least that's what the Sintra salesguy told us.
Why hire anyone to fix a problem when you can make an AI agent to "fix" it, tell investors about it to pump the price, and not fix anything knowing that you have a monopoly?
Yes we did hire SREs, unfortunately they are in another continent and they only know how to pull others into the chat. We also have some AI too, do you want to try them? They are pretty good SREs, one of them wrote 100K lines of code in a week while another one reviews every line along the way. It was fantastic! Fantastic!! FANTASTIC!!!
Readit News
https://github.com/google-gemini/gemini-cli/issues/16750
https://github.com/google-gemini/gemini-cli/issues?q=is%3Ais...
I really hope that didn't send emails out to people.
https://en.wikipedia.org/wiki/Rules_of_Go#Ko
Even self-hosting would have been more stable than sitting on GitHub as predicted more than half a decade ago. [0]
Now there is no 'CEO of GitHub' to contact this time (Satya does not care).
[0] https://news.ycombinator.com/item?id=22867803
Deleted Comment
I once read someone commenting "Nobody writes code by hand without looking syntax up".
Man, you are just outing yourself as a complete beginner, the field is way deeper than you imagine and it's not even close.
The problem is that it's not enough. The fact that Github uses Git specifically is a technical detail; it could use mercurial equally easily, as Bitbucket used to. Github Actions, OWNERS files, PRs and review tools, issue tracker, wiki are all not Git features.
I've been looking into having a separate git server that we can commit to and add plain ole git hooks to, and just having it be synced with github as a clone.
PRs and code review are not. CI/CD is not.
I mean, there are solutions, but none of them seems to have a large enough mindshare and efficiency. (Even though Github's code review tools are pretty spartan.)
They can be. A PR can be made and code review conducted by submitting a patch to a mailing list. That's how the kernel and, I think, git itself is developed.
CI/CD is really a methodology. It just means integrating/deploying stuff as soon as its ready. So you just need maintainers to be able to run the test suite and deploy, which seems like a really basic thing.
I did this in 2019, it avoided so many headaches. CI is better too since there's a nice clean mapping of build -> pod for everything and I can just exec in if something's borked.
I probably only babysit it for 30 minutes per year, including all the upgrades.
Working on the GitHub Azure migration and for years it's gone so well so far.
OK I have no idea about MSFT SREs, just to be /s.