Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
68% Positive
Analyzed from 1357 words in the discussion.
Trending Topics
#forgejo#tangled#gitea#code#review#self#forges#https#source#org
Discussion Sentiment
Analyzed from 1357 words in the discussion.
Trending Topics
Discussion (31 Comments)Read Original on HackerNews
Anyone remember that? It used to be such an important website and went down the tubes.
I use Digital Ocean and run a Nomad cluster on top of that. Gitea and its action runner builds container images and then pushes nomad job definitions to the cluster. I have zero downtime deployment and rolling deploys. Dagger.io is in there somewhere to make local CI mirror what happens in the action runner.
Setting up Gitea was honestly just an afternoon of work. The sqlite database is backed up to Cloudflare R2 and the code is mirrored. It's unlikely that my project will take off to the point that I'll need to upgrade Gitea to something else, but it's extremely easy to setup, maintain, and build CI/CD on top of.
While there are some problems with open source projects self-hosting their forges without federation, that’s really not the end of the world IMO (but lots of love for Tangled nevertheless).
Moved over from Sonatype Nexus to Gitea Packages as well since administering Nexus is annoying: https://docs.gitea.com/usage/packages
However for CI I use WoodpeckerCI (previously used Drone but migrated over), it works well with containers and is delightfully simple: https://woodpecker-ci.org/
Though I guess in my case I don't collaborate with others much outside of work, so it's just something to interact with across computers and servers.
https://forgefed.org/
* https://forgefed.org/
No idea what went wrong with ForgeFed, yeah.
---
Edit:
> Cool. It's been years since ForgeFed came out but it isn't anywhere nearly as federated as Tangled is. What gives?
Just read your other comments. Sorry, but I must point out that it would be polite to disclose that you’re working on Tangled, especially when posting takes like this on a competitor technology.
It will likely require some grant money to become usable.
(but what I'd know, I thought this was about typography forges - didn't know there were also software forges...)
Whereas in the "forges" space, it seems Tangled drives federation forward much faster than the ActivityPub-based federation features of Forgejo/Gitea (which are progressing really slow).
What I like about (the idea of) ForgeFed is that it lets existing forges speak to each other.
In practice I probably just need Forgejo and GitLab to be able to speak to each other.
I believe the future of GitHub, for me, is to solve two problems:
So many times when I try to visit the source code of some package uploaded to crates.io, the self-hosted git no longer exists.GitHub repos sit stale for decades.
For day-to-day reliance, my self-hosted Forgejo and CI runners have better uptime.
Only pet peeve with Forgejo:
What a luxury problem, but still.I'd like to see more hosted Forgejo solutions pop up; it's very low-resource cost.
I think the main attractive thing about Tangled is that it supports proper stacked PRs. But on the other hand it doesn't support private repos at all, and Github is getting stacked PR support soon (fucking finally)...
It's hard to see the advantage of Tangled over Codeberg for example.
https://codeberg.org/forgejo/design/pulls/48
Which is totally understandable.
Managing a healthy highly-popular open-source codebase requires effort to not bloat it.
Which brings me back to wanting good APIs for native Kubernetes CI runners and time-limited PATs for agentic coding.
I can vibe that in a day. But it sure as heck won't be aligned with the future of all Forgejo users.
I would not call stacked PRs bloat. It's a super important workflow. The fact that Github hasn't supported it for so long is insane.
Also, could you describe the current code-review process for Tangled in more detail please?
My belief is that code review should happen locally, and the unit of work being reviewed stays independent from unit of work being "submitted". The reviewer should be able - locally or in the WebUI - to specify a change-/revision-set (preferably via jj revset language), or add files to review ad-hoc, or even mark specific lines for review!
And then, assign comments to such a review unit - where changes are all being captured as a first-class object, with all the niceties that may come together, e.g.:
- comments are captured in the jj oplog as if they were code changes
- it's easy to surface (locally or in the WebUI) past code reviews
- it's easy to "untangle" and grasp which particular comment belongs to which code review
- [vague from my side] comment might belong to multiple code reviews, or might not; code review might belong to multiple revsets
Members elect the board which chooses the CEO. A cooperative, in other words. The tech is a solved problem, with lots of open source around to do it. Enough members means paid operations and development staff, or outsourcing one or both, or grants to open source devs, etc. The possibility is there.
That's how we prevent cultural drift: by actually controlling the company.
Like https://codeberg.org/? :-)
How about some non-Git forges (like Mercurial forges)? That's what I'd like to see.
I don't think it would take years for an AI first platform to enshittify, it would be instant.