Live data from Hacker News

The forge we deserve

btao.org

21–30 of 57 posts

Re: The forge we deserve

#21
post #5

I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members. 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 possibi…

hear hear!

Re: The forge we deserve

#22
post #16

Tangled and Radicle are both really cool, but add too much mental gymnastics compared to just running Forgejo. 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: - Discoverability for public open-source projects - Backup sin…

I agree, these things just seem to add too much mental complexity compared to the advantages. Even the sign-up process is wierd, e.g. I put in my username as `dave` but if you try to log in as `dave` it says "did you mean dave.tngld.sh?" What? Then when you log in it takes you immediately to a second OAuth screen where you have to put your password in again, immediately after you logged in. I'm sure they would try to justify this bad UX with technical reasons...

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.

Re: The forge we deserve

#23
post #16

Tangled and Radicle are both really cool, but add too much mental gymnastics compared to just running Forgejo. 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: - Discoverability for public open-source projects - Backup sin…

I agree, these things just seem to add too much mental complexity compared to the advantages. Even the sign-up process is wierd, e.g. I put in my username as `dave` but if you try to log in as `dave` it says "did you mean dave.tngld.sh?" What? Then when you log in it takes you immediately to a second OAuth screen where you have to put your password in again, immediately after you logged in. I'm sure they would try to…

It seems like Forgejo isn't actively planning to have stacked PRs:

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.

Re: The forge we deserve

#24

I personally just self-host. The project that I'm working on right now uses Gitea internally with an action runner. 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 ru…

Codeberg runs on Forgejo (a Gitea fork) and is fairly big, so you’re in a good company. Maybe you’ll need to swap in another database, but SQLite is surprisingly powerful, too. 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).

Mmm, this is for an Etsy-lite website ( https://plukio.com ) though honestly I've used Gitea for YEARS - even back when it was Gogs.

Re: The forge we deserve

#25

Earlier quoted context omitted.

Codeberg runs on Forgejo (a Gitea fork) and is fairly big, so you’re in a good company. Maybe you’ll need to swap in another database, but SQLite is surprisingly powerful, too. 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).

Also running Gitea, pretty pleasant experience! 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 wo…

Gitea has artifact support?! We are truly blessed.

Re: The forge we deserve

#26

Earlier quoted context omitted.

Also running Gitea, pretty pleasant experience! 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 wo…

Gitea has artifact support?! We are truly blessed.

Yep, including container images!

Re: The forge we deserve

#27
post #14

It seems ironic, that in the social media space, AT protocol based instances are basically centralised (Bluesky) and ActivityPub based instances (Fediverse, Mastodon) have a much healthier grade of federation. 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).

That might just be your observation bias. I have not seen any Tangled instances in the wild.

Re: The forge we deserve

#28
post #12

The forge we deserve is the one that is built for jj and local review.

Tangled is built for jj :) We support stacking using jj change ids: https://blog.tangled.org/stacking

Is code review a first-class concept in Tangled?

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

Re: The forge we deserve

#29
post #23

Earlier quoted context omitted.

I agree, these things just seem to add too much mental complexity compared to the advantages. Even the sign-up process is wierd, e.g. I put in my username as `dave` but if you try to log in as `dave` it says "did you mean dave.tngld.sh?" What? Then when you log in it takes you immediately to a second OAuth screen where you have to put your password in again, immediately after you logged in. I'm sure they would try to…

It seems like Forgejo isn't actively planning to have stacked PRs: 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 th…

> Which is totally understandable. > Managing a healthy highly-popular open-source codebase requires effort to not bloat it.

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.

Post reply on HN