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

Gitea 1.19

blog.gitea.io

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Gitea 1.19

#71

Post by dave78 »

jpace121 wrote: post #62
dave78 wrote: post #10

What are the current thoughts on Gitea vs Forgejo? I'm thinking of migrating from a self-hosted Gitlab to one of them in the near future. The way Gitea was taken over leaves a bad taste in my mouth so I'm leaning towards Forgejo, but it's not really clear to me if that's the right choice.

Forgejo currently is only applying branding changes and currently plans on being a soft fork. I think it’s existence is a good thing for the ecosystem (if Gitea the Company did something wonky, there will be an organized group already doing releases ready to go), but I’m not sure there is a huge benefit in running it, at this juncture.

The other discussion in this thread has convinced me that for now, the momentum seems to be with Gitea, so I'll probably lean towards that. I'm still disappointed in how the whole situation was handled, though, and it leaves me wondering what other changes will be around the corner.

Re: Gitea 1.19

#72

Post by remram »

dave78 wrote: post #67
remram wrote: post #63

Earlier quoted context omitted.

It seems that they have "soft forked" act as well. I worry that they will spend more time maintaining all their forks than doing any original development...

Gitea soft forked act as well, from https://gitea.com/gitea/act : "This is a custom fork of nektos/act, for the purpose of serving act_runner. It cannot be used as command line tool anymore, but only as a library. It's a soft fork, which means that it will tracking the latest release of nektos/act."

I see, removed that from my comment then, sorry. I looked at their go.mod and assumed.

Now I worry even more about everyone maintaining forks of everything rather than doing original development.

I wonder what differences there are between Gitea's and Forgejo's forks, and also why they couldn't work with upstream.

Re: Gitea 1.19

#73

Post by lagniappe »

djha-skin wrote: post #24

I'm super excited Gitea is becoming better and better. Gotta be honest though; the really exciting feature I'm waiting for is ActivityPub[1] support. That will really make my single gitea instance much more interesting, when I can accept PRs from other instances and make them to theirs. A lot of comments about "Forgejo". In short: meh. Not a big deal[2]. I'll be sticking with Gitea. 1: https://github.com/go-gitea/git…

is it for-guh-joe or for-jeh-ho?

Re: Gitea 1.19

#74

Post by jolheiser »

lagniappe wrote: post #73
djha-skin wrote: post #24

I'm super excited Gitea is becoming better and better. Gotta be honest though; the really exciting feature I'm waiting for is ActivityPub[1] support. That will really make my single gitea instance much more interesting, when I can accept PRs from other instances and make them to theirs. A lot of comments about "Forgejo". In short: meh. Not a big deal[2]. I'll be sticking with Gitea. 1: https://github.com/go-gitea/git…

is it for-guh-joe or for-jeh-ho?

I am not with the fork, but seeing as people ask this about us all the time I can relate.

https://forgejo.org/static/forgejo.mp4

Re: Gitea 1.19

#75

Post by techknowlogick »

RealStickman_ wrote: post #70
jolheiser wrote: post #35

Earlier quoted context omitted.

Out of curiosity, why did that stand out? We've had the .com domain for a little while, so now we're starting to consolidate things to it.

Honestly, it's a stupid response from me, but it did feel like a reminder of the recent changes.

No worries, that's totally understandable. The change was made mostly for practical reasons, to be able to upgrade infrastructure piece by piece. So both new and old infra could run at the same time while it was switched. I'm actually writing a blog post detailing the history of our infra, but the TLDR is that too much money and person effort was being spent on managing the infra.

Disclaimer: I am a part of the Gitea TOC, and am employed to work on Gitea.

Re: Gitea 1.19

#76

Post by sangnoir »

mariusmg wrote: post #17
barnabee wrote: post #6

For info: there was some drama a while back [0], [1] and some (a lot?) of the community/devs went to https://forgejo.org/ Seemed to me like they had a point and it's worth considering following that project [2] instead. [0] https://gitea-open-letter.coding.social/ [1] https://news.ycombinator.com/item?id=33372471 [2] https://codeberg.org/forgejo/forgejo

>and some (a lot?) of the community/devs went to https://forgejo.org/ The Forjero commits prove that this is incorrect (they are still busy removing Gitea branding related things from their code). It's going to take a long time until they begin to match the Gitea momentum.

> It's going to take a long time until they begin to match the Gitea momentum.

I'd hope so! I am not interested in many of the features being added to Gitea (i.e. the momentum you allude to[1]). I want a light binary I can continue to self-host on a Raspberry Pi Zero that doesn't have Docker installed.

1. I feel Gitea is being positioned as a competitor to GitHub and GitLab - good for them! However, the previous iteration was close to perfect for my needs, albeit not very monetizable. I'm glad it got forked and will be side-grading to Forgejo.

Re: Gitea 1.19

#77

Post by jonas-w »

djha-skin wrote: post #60
joencott wrote: post #49

Earlier quoted context omitted.

Forgejo did relicense, there was a democratic vote and the it was agreed to finally relicense to a license that respects user's freedoms

Very cool if true, but it appears they haven't done it yet: https://codeberg.org/forgejo/forgejo/src/branch/forgejo/LICE... Could someone post a link to the decision?

https://codeberg.org/forgejo/meta/issues/183

I think, this seems to be the discussion everyone is talking about

Re: Gitea 1.19

#79

Post by joencott »

sangnoir wrote: post #76
mariusmg wrote: post #17

Earlier quoted context omitted.

>and some (a lot?) of the community/devs went to https://forgejo.org/ The Forjero commits prove that this is incorrect (they are still busy removing Gitea branding related things from their code). It's going to take a long time until they begin to match the Gitea momentum.

> It's going to take a long time until they begin to match the Gitea momentum. I'd hope so! I am not interested in many of the features being added to Gitea (i.e. the momentum you allude to[1]). I want a light binary I can continue to self-host on a Raspberry Pi Zero that doesn't have Docker installed. 1. I feel Gitea is being positioned as a competitor to GitHub and GitLab - good for them! However, the previous iter…

> (i.e. the momentum you allude to[1])

The momentum stalled when the community was plagued recently by toxic behaviour of one of the members who started the fork. He had to step down from the "well-being" team[1], bullied a moderation team member into stepping down[2] and forced him to disclose information from a private chat[3].

Now he is trying to "reboot" the community to erase his previous bad behaviour [4]

Forgejo members are also unhappy about conflicts of interest of this individual [5]

The Forgejo community is stronger than this one individual, so it will succeed.

[1]: https://codeberg.org/forgejo/meta/commit/d822fc3b90f79372023...

[2]: https://codeberg.org/forgejo/meta/issues/176#issuecomment-82...

[3]: https://codeberg.org/forgejo/meta/issues/176#issuecomment-82...

[4]: https://codeberg.org/forgejo/meta/issues/187

[5]: https://codeberg.org/forgejo/meta/pulls/180#issuecomment-843...

Re: Gitea 1.19

#80

Post by KronisLV »

candiddevmike wrote: post #4

Really excited for Gitea Actions!! Will probably look into switching from GitHub now. Wasn't a fan of drone or having to maintain the integration with a separate CI/CD system.

> Wasn't a fan of drone or having to maintain the integration with a separate CI/CD system.

I'm in the opposite camp, especially when this separate system is as simple as Drone CI or Woodpecker CI (I mostly use the former, but the latter is more permissive, license wise). I came to holding this view after I ran into some issues by using a self-hosted GitLab Omnibus install previously: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...

Using separate systems for working with the code, doing CI/CD and storing artifacts made each of the parts easier to update, limit the resources available to each, as well as limited the fallout when something does go wrong - say, still being able to interact with the codebase, even if the container repo is temporarily unavailable, or vice versa.

That said, in a few years I might come around to holding the opposite views again - frankly, both approaches are good and seeing the Gitea Actions project is nice! Though I'll also acknowledge that some might claim that all-in-one solutions are sometimes a bit half-baked, a criticism that I've heard of GitLab in the past (though honestly they're also fine, especially for the more enterprise settings, where you have beefier servers and a few people to manage the install).

Post reply on HN