141–150 of 152 posts
Earlier quoted context omitted.
Why the downvotes? If you want real security, self-host your Git repo.
I'll bite. So you want to host a git repo. You need to manage SSH keys then, and then you'll want bug tracking and PRs for code reviews. This means that you need to host something like Gitlab, which is not free if you want features like SSO.
Earlier quoted context omitted.
yesterday I couldn't set up a bunch of servers that I needed provisioned and cloudflare's API had an outage. Today if I were using github, my day would be wasted again. For all the talk about companies trying to cut out on meetings by putting a sticker price to it (this 30 minute meeting could've been an email and cost $2000), at what point do we start saying "this outage could've been avoided and cost us $5k"?
Avoided how, by spending $50,000? Times that by the the number of external systems you rely on and you start seeing why we outsource that stuff in the first place.
And I can take part of the "savings" and contribute to gitea's further development.
Earlier quoted context omitted.
People will take issue with any wording. Why try to find the exact right words each time when people will have exactly the same complaints?
I take issue with clear PR-speak trying to make the issue lesser than it actually is. When you're having an outage- call it an outage. Having a feature completely unusable and labeling it as "degraded performance" is clearly twisting your words to lessen the outwardly perception of the scale of the problem.
People are going to jump on them no matter what. Having a engineers talking to PR wouldn’t help anyone.
Earlier quoted context omitted.
I know this a greybeard's fantasy and that most people working today were trained not to bother, but: important things should not have GitHub as a failure point . Hobby projects and today's work? Sure. Point straight at GitHub and hack away. And when it goes down, get yourself a coffee. But everything that's anywhere near production should have already pointed those github requests to a mirror or other tool in your o…
It's not that black and white. Where do you draw the line on what can and can't be a failure point? My cloud provider is probably an acceptable point. If every AWS region goes down I'm not going to have a spare cloud provider. What about an auth provider? Do I need a backup there? What about CI, do I need multiple CI systems? 3rd party search services, realtime messaging services, the list goes on. For 1% of systems,…
Relying on Google for that would probably be a mistake. With cancelled projects and cancelled users, that's high risk.
Earlier quoted context omitted.
The "nothing to see here" approach to access control has a lot of weird culture-consequences. I wish software would just address me like the peasant that I am, rather than trying to gaslight me into believing that my artificially limited world is the whole one.
I think you don't want to reveal the presence of projects by name or not -- just the name of repo could be sensitive info, potentially.
Earlier quoted context omitted.
Fossil does this within the repo, maybe we need a way for Git to do so too.
... Or use Fossil?
Earlier quoted context omitted.
Fossil does this within the repo, maybe we need a way for Git to do so too.
Rather than making it a feature of git, it would probably be sufficient to have a tool that packed issues and PRs from the forge into the repo (in preparation to be migrated) and then unpacked them into the forge's API on the other side.
Fossil lets you synchronize artifacts both ways, so you can clone a repo, participate in discussions when on a plane, write some replies, connect back to the internet and sync them back up to the server.
When your server goes down, you don't lose anything. There's no need to remember to back up your issues every day, every time you clone the repo, you also clone its tickets, forum, wiki etc.
Earlier quoted context omitted.
Problem is, this is one of 50 things that can go wrong for which you should have a robust backup plan for
If you’re using 50 things requiring separate backup plans, and you aren’t large enough that it’s also no problem to organize backup plans for those 50 things, you’re doing something wrong, I’d say.