Live data from Hacker News

Evaluating new software forges

notgull.net

111–120 of 138 posts

Re: Evaluating new software forges

#111
post #15

> Rather than needing a complicated YAML file to run a CI system, it’s just cloning Git repos and running commands. How do you define what repos you need and which commands are run? Ah, it is indeed also a YAML file: https://srht.site/automating-deployments

But is it a _complicated_ YAML file?

On other CI systems it is also a good idea to only use the YAML file to call a bash/python/deno/... script which does the actual work.

Re: Evaluating new software forges

#112

Earlier quoted context omitted.

The layout of radicle.land is unfortunately pretty broken on mobile.

What is radicle.land? Both radicle.xyz and app.radicle.xyz seem fine for me on Firefox mobile. Did something change in the last few hours?

They probably meant protocol.land.

Re: Evaluating new software forges

#113
post #53

Earlier quoted context omitted.

What I understood is that the author is not happy about the “Open Core” model and would prefer truly OSS, but the real deal breaker is maintaining Gitlab. My experience self hosting Gitlab was pretty terrible, it requires a lot of attention on your part, and internally the project feels like a bunch of fragile scripts. There’s also little documentation for when things go wrong, with was almost every single update. In…

I've been running the GitLab Omnibus for 4 years now. Easiest upgrades ever. Never once had a bad update that required manual workarounds.

We run a self-hosted Gitlab Premium instance installed with Omnibus for 30 devs and we actually install Gitlab updates on a cron.

Had two upgrades that needed minor manual intervention in 5 years. Uptime better than Github despite the #yolo approach.

Re: Evaluating new software forges

#114
post #54
post #17

Earlier quoted context omitted.

There is also https://protocol.land and https://gitopia.com .

The latter is Web3/crypto la la land, and the former.. dunno, got to read the code, but I would like to know about the project, its goals, and who is behind it.

Both (and Radicle) are web3.

So, it's probably not your jive.

Re: Evaluating new software forges

#115

Earlier quoted context omitted.

> I used his media host/imgur alternative in the past, and it spontaneously just disappeared one day. I'd rather that not happen to my source code Git is decentralized.

Git is decentralized. Ticketing systems and mailing lists as found on SourceHut and many other forges aren’t. And if SourceHut disappears, what would you do with the repository? You’d upload it to a new forge, but how would you tell users where to find it, how would the users know this is the original source and not a hostile fork? It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLa…

> It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLab instead of SourceHut.

It's better to not make yourself (much) dependent on functionalities that only the respective software forge provides.

Re: Evaluating new software forges

#116

Earlier quoted context omitted.

Git is decentralized. Ticketing systems and mailing lists as found on SourceHut and many other forges aren’t. And if SourceHut disappears, what would you do with the repository? You’d upload it to a new forge, but how would you tell users where to find it, how would the users know this is the original source and not a hostile fork? It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLa…

> It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLab instead of SourceHut. It's better to not make yourself (much) dependent on functionalities that only the respective software forge provides.

What would you suggest instead? How would you replace pull requests, or even sending patches via email to mailing lists?

Re: Evaluating new software forges

#117
post #82
post #53

Earlier quoted context omitted.

What I understood is that the author is not happy about the “Open Core” model and would prefer truly OSS, but the real deal breaker is maintaining Gitlab. My experience self hosting Gitlab was pretty terrible, it requires a lot of attention on your part, and internally the project feels like a bunch of fragile scripts. There’s also little documentation for when things go wrong, with was almost every single update. In…

I found it difficult to find documentation on how to run gitlab in docker without nginx (I use caddy for reverse proxy) and enable the registry. For anyone having the same problem, here's a working Dockerfile. https://gitlab.tandav.me/tandav/notes/-/issues/5516 I've tried github actions, drone, woodpecker and gitlab. In my opinion gitlab has a much more flexible CI system.

I was searching everywhere for this 3 months ago, then switched to forgejo lol. Good tip though.

Re: Evaluating new software forges

#118

One of the things that people should know about SourceHut is that even though it is "Free Software", it is not a very "free" platform. Certain types of projects are a red line to the owner and will be removed[0]. I'll be honest, I do not trust cryptocurrency stuff and don't believe that it has utility. I hold none, I don't use it. That being said, this makes me wonder what the next category of projects that SourceHut…

+1. I moved from Sourcehut when it announced IRS change of TOS. I realised I would prefer to support less discriminatory forges.

I also have no interest in crytocurrency.

Re: Evaluating new software forges

#119

Earlier quoted context omitted.

> It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLab instead of SourceHut. It's better to not make yourself (much) dependent on functionalities that only the respective software forge provides.

What would you suggest instead? How would you replace pull requests, or even sending patches via email to mailing lists?

I'd don't really see a difference between sending an email to a list or to a maintainer. Maybe that's an argument for not adding and adapting to unnecessary concepts like a web based pull request.

Re: Evaluating new software forges

#120

Earlier quoted context omitted.

What would you suggest instead? How would you replace pull requests, or even sending patches via email to mailing lists?

I'd don't really see a difference between sending an email to a list or to a maintainer. Maybe that's an argument for not adding and adapting to unnecessary concepts like a web based pull request.

What if there’s more than one maintainer? How do you build any sort of community without a place for discussion?
Post reply on HN