Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The forge we deserve

btao.org

Post reply on HN
Print view View original

41–50 of 57 posts

Re: The forge we deserve

#41

Post by notdefio »

drdexebtjl wrote: post #38

I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges? A project’s issues and pull requests are only useful for that project. The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, as…

On a GitHub issue page, it will show backlinks to anywhere on GitHub that issue has been referenced. This is quite helpful at times because it leads me to find how other teams have worked around an issue I'm dealing with.

There's value in related information being aggregated and linked across many projects.

Re: The forge we deserve

#42

Post by drdexebtjl »

edent wrote: post #40
drdexebtjl wrote: post #38

I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges? A project’s issues and pull requests are only useful for that project. The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, as…

> A project’s issues and pull requests are only useful for that project. I don't think that's always true. A bug in library A might be referenced in project B with a fix in fork C. Yes, a hyperlink works to show you where to find info. But it doesn't alert you when a PR on C is merged by A meaning that B is now unblocked.

Fair point.

That said, I don’t think that works well in a single centralized forge today either. Usually you still need A to actually make a release with the fix, which isn’t tracked by the issue/PR system.

Re: The forge we deserve

#43

Post by sshine »

IshKebab wrote: post #29
sshine wrote: post #23

Earlier quoted context omitted.

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.

It’s not bloat.

The argument is maintainer bandwidth/fatigue.

From the closed issue:

> Closing this out for the time being, as noted previously (I'm currently leaning towards designing some review refinements and shelving the stacked concept design for the moment) and to clarify that it isn't current and active work.

Re: The forge we deserve

#44

Post by lavela »

colesantiago wrote: post #34
lavela wrote: post #33

To me being VC funded is the opposite to "structurally resistant to the lock-in". I'm not against VC funding everywhere, but I don't want it at the core of my development stack.

I think Codeberg, Forgjo, GitLab (Self Hosted) and Gitea are great OSS alternatives where it is funded by the community and should be great for long term support of your (and my) dev stack. > I'm not against VC funding everywhere, but I don't want it at the core of my development stack. Then you should avoid and steer very clear of Tangled since it is VC funded and crypto VCs are invested in this forge. The direction…

> Then you should avoid and steer very clear of Tangled since it is VC funded

Yes, that's what I'm referring to. Could have made it clearer.

Re: The forge we deserve

#45

Post by preya2k »

omnimus wrote: post #35
account42 wrote: post #27

Earlier quoted context omitted.

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

The federation mechanism that will win will be the one that forgejo/gitea supports first. Everybody is moving either to codeberg or more likely forgejo instance.

Forgejo already supports ActivityPub, albeit only for a minor use case (starring repos), so according to your definition, it's decided already.

Re: The forge we deserve

#47

Post by jorams »

BrenBarn wrote: post #6

> So, what’s next? There are a lot of Git forges out there. How about some non-Git forges (like Mercurial forges)? That's what I'd like to see.

Sourcehut supports Mercurial, if the email workflow is your cup of tea. There's also Heptapod, which I believe is a fork of GitLab with added Mercurial support. I'm not aware of any Tangled or Radicle-like initiatives supporting it though.

Re: The forge we deserve

#48

Post by edent »

drdexebtjl wrote: post #42
edent wrote: post #40

Earlier quoted context omitted.

> A project’s issues and pull requests are only useful for that project. I don't think that's always true. A bug in library A might be referenced in project B with a fix in fork C. Yes, a hyperlink works to show you where to find info. But it doesn't alert you when a PR on C is merged by A meaning that B is now unblocked.

Fair point. That said, I don’t think that works well in a single centralized forge today either. Usually you still need A to actually make a release with the fix, which isn’t tracked by the issue/PR system.

I'm not sure. On GitHub I see plenty of bug reports which say "this is broken" with references to other repos. Those backlins are useful when someone does figure out the fix.

That said, I'm very much in favour of people and projects moving away from GitHub.

Re: The forge we deserve

#49

Post by hannasm »

I'm currently looking to piece together a kubernetes native "forge" and there are major gaps in the ecosystem. Why do we need everything in one application like every single "forge" claims to be? What about when I want something that's not supported.

How about Forge compatible components? Or forgeables? Naming is hard but hopefully you get the point...

I'm an expert, I'll go to harbor freight and weld some stuff together. It will still break down in 5-10 years but maybe I will at the very least have some control over the way I pivot.

Re: The forge we deserve

#50

Post by BrenBarn »

jorams wrote: post #47
BrenBarn wrote: post #6

> So, what’s next? There are a lot of Git forges out there. How about some non-Git forges (like Mercurial forges)? That's what I'd like to see.

Sourcehut supports Mercurial, if the email workflow is your cup of tea. There's also Heptapod, which I believe is a fork of GitLab with added Mercurial support. I'm not aware of any Tangled or Radicle-like initiatives supporting it though.

Yeah the email workflow is not my cup of tea. :-) Heptapod seems promising in some ways, but from what I saw it's entirely based on topics (not branches or bookmarks) which is also a peculiar workflow. Plus it doesn't have anything comparable to Github in terms of providing free hosting; in theory you can get free hosting for an open source project but you have to apply. At one point around when they launched, Heptapod said something like "we don't want to be a place for people to host their random side projects", but that's exactly what I'm looking for. I was pretty happy with Bitbucket before they dropped Mercurial support.
Post reply on HN