Blender moves from Phabricator to Gitea | Hacker News Reader

Blender moves from Phabricator to Gitea

code.blender.org

124 pointsstephdin57 comments

One note on Phabricator: "Effective June 1, 2021: Phabricator is no longer actively maintained"

Maintenance has been picked up by the community under a new name, viz. Phorge.

This is an interesting move in the context of the recent kerfuffle around Gitea - context: https://news.ycombinator.com/item?id=33749757

I wonder whether this was part of discussion on the migrating within the Blender team or whether their migration just started before the Gitea org-change.

---

Off-topic but it's also funny that the Phabricator fork is Phorge & the Gitea fork is Forgejo...

The decision to move to gitea was made before that announcement.

I wonder if gitea decided to become a company after they saw the interest from Blender. I know blender folks were asking questions about the long term future of the project.

For reference, here are threads asking for proposals on solutions to consider and announcement of gitea being picked:

- https://devtalk.blender.org/t/developer-blender-org-call-for...

- https://devtalk.blender.org/t/developer-blender-org-choice-f...

On the topic of gitea, I rummaged through the thread and it seems they want to make a decision in the first months of this year. I'm not sure these people are fit to run such a platform if they don't understand the problem with "we'll ban code doing xyz because we don't like it" for such a project. I was really looking forward to codeberg, but I also have a bunch of infosec stuff in my repos, including malware/PoC's etc. but I don't want to risk getting banned.

We need something like self-hosted gitea plus fediverse-driven socials mimicking github.

/edit: there is actually work being done by forgefed.org, radicle.xyz and forgejo is implementing federation here: https://codeberg.org/forgejo/forgejo/issues/59

The comments on codeberg aren't really relevant in this thread - codeberg is a hosting platform, any policies they implemented would apply to accounts on their platform only, not to self-hosting users of gitea/forgejo/whichever.

That said, as long as the underlying software is self-hostable, I actually think platforms taking a curatorial approach is pretty cool. E.g. Mastodon instances do this with moderation, but also make it easy to have multiple accounts on different instances for different purposes.

I already do this with git hosts so I can see it working well.

Well, as far as I understand, the fork forgejo is done by codeberg [1] so I see it as relevant. Wasn't that the commotion you meant?

But yeah I agree, federated gitea/forgejo and then I wouldn't care about their ToS because I could roll my own. Nowadays code-hosting is so social that I would declare it even a social network in a kind of way. Really looking forward to the federation of gitea/forgejo!

> I already do this with git hosts so I can see it working well.

Can you elaborate?

[1] https://blog.codeberg.org/codeberg-launches-forgejo.html

> Well, as far as I understand, the fork forgejo is done by codeberg [1] so I see it as relevant. Wasn't that the commotion you meant?

Forgejo was started independent of Codeberg - Codeberg later became the project's "custodian".

From the Forgejo site:

> we are very proud that Codeberg e.V. has decided to become our project’s custodian. Codeberg e.V. is a non-profit organization with a stellar reputation, that is dedicated to the success of the Free Software movement. They provide software development services to FOSS projects at Codeberg.org. They are rapidly growing and hosting more than 50,000 code repositories for about 40,000 people. Not only will Codeberg take care of the Forgejo domain names and trademarks, but the organization will use Forgejo as the basis for their own services, instead of Gitea.

Full post at: https://forgejo.org/2022-12-15-hello-forgejo/

> Can you elaborate?

I just mean that Git is a distributed model that supports multiple remotes. Having different hosts for different things is not a use-case that's unsupported or difficult with the current software.

Got it, thank you for clarifying!

Makes me wonder what all the other users of phab are doing. I know: twitter, dropbox, freebsd, and mozilla were all using it in some point.

I think haskell moved to GitLab, now Blender's on Gitea.

I'm curious if people are moving to phorge?

Wikimedia still uses phab for bug tracking. Taking a look at phorge Soon™

Not to dunk on Phabricator, but did anyone actually enjoy using it? I always thought it was a mess anyway. Jenkins was also... "jankins". Of course this is all hindsight, but wow it doesn't even seem that long ago.

Considering the alternative at work was an old Bugzilla instance, and code review feedback was done by email, adopting Phabricator was a breath of fresh air: good engineering-oriented tickets (subtasks, task grouping), good code review experience + integration with tickets, a wiki, and a few extra... yeah it really rocked.

Of course, if you compare to Jira's ticket-management experience, and nowaday's github code review, sure, it's quite jank. But for a brief moment, in a period of time at work, Phabricator really shined!

Phabricator's code-review (particularly if you're stuck on SVN) and ticket workflows were both great. Had both a decent command-line and decent web client. A lot of other things were a mess.

I did! I did the Google Summer of Code twice with Blender and ever since I find myself preferring the patch workflow of Phabricator over the merge/pull request found elsewhere. I am comfortable with both, but phabricator just clicked with me better

What was your experience like with GSOC? Gitea has applied to it this year, and are hoping to be able to make it a good experience for any contributor that is matched (hopefully we are accepted as well).

GSoC was a great experience. It was my first time planning a major contribution to an open source project. It would have been much more challenging for me without the help of my mentor and the other core contributors, so it is important to have a good support system for any involved.

My projects were focused on user interface improvements, so I also spent a lot of time gathering feedback from users. It was really valuable for me to learn how to get feedback at different stages of the development cycle, and also to learn how to filter the good from the bad feedback.

I hope Gitea is accepted!

I loved it: the code review system, integrated wiki (despite its custom markdown syntax), integrated kanban, remote repo sync, and the ability to easily and cleanly link everything together. It had its warts but I haven't yet found a single system that does everything that it did well. I know Phorge exists, but it seems to be struggling to get traction, maybe because it appeared just slightly too long after everyone had accepted Phabricator's demise.

Yes, I absolutely loved Phabricator, and still do, even if I don't run my own instance anymore. The code review it offers is still excellent since it's based around stacked diffs, and it had some nice little extras like coverage support, first-class test results from the build reports, etc. The issue tracking is still miles ahead of GitHub and was quite flexible. It had good support for permissions and access levels, and tools like Herald were very useful. Evan also had a very keen eye for many things design wise, and was fun to chat with. I think a lot of the things it did it did very well.

But there were definitely some scope issues and other stuff that could have been handled better. It's hard to keep up with GitHub now that they're pretty aggressive about features, etc. But the core competencies have always been very good in my opinion, and it has a nice, hackable codebase.

The way it handled branches and merging was an absolute nightmare. IIRC it did this super weird thing that when you put up a diff from the CLI, it made its own little temporary branch for you. And god forbid if you pushed up your branch remotely, it would get all confused and start diffing against that remote branch. Literally couldn't merge via the UI, the CLI was the only way.

To be fair, the review system was better than GitHub. It's insane that even today, there's no way to tag your team and have them stay tagged. If anybody comments or reviews, they're dismissed. This is an issue that's been open for nearly five years. [1]

[1] https://github.com/community/community/discussions/5289

Is Gitea code review any good? If they cloned Github it's going to be an inferior experience compared to Phabricator.

And this blog post describes their adventure: https://code.blender.org/2022/07/gitea-diaries-part-1/

Which includes the famous start of the gitea shitstorm: "And, quite significantly, we’re in the finishing stages of having a support agreement with the Gitea project to have them support us in our migration by funding work on missing features, code and bugfixes that will be available 100% to Gitea users under Gitea’s MIT license."

I wonder how Gitea will hold up to all the traffic? Even Gitea hosts their stuff on Github.

Gitea is self-hosted, so Blender will be running their own instance.

That's not what parent means. Gitea is an alternative to GitHub, yet they use GitHub for hosting their code.

That kind of makes sense for disaster planning though.

If Gitea discovered some massive CVE, and volentarily went dark to fix it... They would want their code and fix hosted somewhere else.

Mirroring the code to github (or somewhere else) would solve that problem just as well.

Not dogfooding your own product seems like a huge red flag to me.

There's clearly the intention to self-host, they seem to be waiting for support to ingest data from a GitHub data export which seems pretty reasonable.

Yes, this is exactly the case. Lots of data, and low ratelimits don't mix. All except for the main repo have already migrated to gitea.com

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

I don't believe Gitea is hosting on Github for traffic reasons but for feature completeness. Relevant issue is here[0].

[0]https://github.com/go-gitea/gitea/issues/1029

That's a great ticket, & also links to a really nice & insightful comment from one of the Fog Creek folk https://lobste.rs/s/gokjbo/gitea_1_1_0_released#c_dg9pwe

I still dream of a world where FogBugz & Kiln gained the respect they deserved.

Mercurial was pretty damn nice.

Was? It still is very nice.

Looks like https://github.com/go-gitea/gitea/pull/18165 is the last missing checkbox...

Gitea does not use Github because the software can't handle their load requirements, but because they started using GH before Gitea had all the features they needed. They are actively working on hosting Gitea on Gitea, with the last piece being an importer to move over all their GH data.

Blender seems to have been ok manually migrating some things and abandoning other things, since they weren't likely to ever get a Phab->Gitea importer anyways.

https://github.com/go-gitea/gitea/issues/1029

How much traffic could they possibly have? Quite frankly either gitea has absolutely terrible scalability or something else is off here.

Edit: i misread the parent comment. My bad.

Huh? It isn't because of inability to handle load, that they host on GH.

Gitea performs alright. It can serve surprisingly-heavy traffic from a potato-tier VM with a SQLite backend (assuming the host network can keep up with it, anyway). Not Github-scale (but Github has... a lot of traffic, including a whole lot of write traffic) but quite a bit, and that's with basically the worst-possible hosting situation for handling high load.

That's correct. It is not due to load, gitea.com already has most of the projects repos migrated already, just not the main one due to ratelimits and exporting all the issues. Gitea.com has thousands of users, and multi-TB traffic monthly on a fairly modest setup.

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

Tbf my comment was phrased a bit ambiguously, but I couldn't think of anything less ambiguous.

Doubt it'll be a problem.

Github's scaling challenges have more to do with the write volume than the read volume. Even a project as big and active as Blender shouldn't make Gitea sweat too much on relatively modest hardware. Anonymous clones and such will surely be https, so, quite cache-friendly.

I wanna say Gitea has some config options for hosting static files (like releases) on s3-compatible storage then serving directly from there, so even that shouldn't be a problem. But I may be mis-remembering that part. And, again, a CDN or Varnish or whatever would be able to serve those files just as well from Gitea as from anywhere else.

Yup, that's right. Non-repo data (releases, avatars, packages, etc..) can all be hosted in s3-compat storage.

If you are interested in some benchmarks that Blender did you can find them here: https://code.blender.org/2023/02/gitea-test-drive/

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

Hi, I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea. The reason why the project itself is still on GitHub is due to the massive amount of metadata (20K+ issues and PRs, and all the comments, reactions, and other metadata attached to them) around the project, and the ratelimiting that is slowing the export. All the non-primary repos have long since moved to gitea.com.

I start getting worried about projects when people say stuff like "I'm one of the members of the technical oversight committee of the Gitea project"

How many committees are there and how many people on each committee?

The TOC is our owners team, but three are from the company and three are from the community.

The reason to say it as a disclaimer is because we are going to have some bias.

You can use the API to export all of the metadata in a single request:

https://docs.github.com/en/rest/migrations/orgs#start-an-org...

https://docs.github.com/en/rest/migrations/orgs#download-an-...

Using a Github App you get 15K requests per hour. Even with pagination(100 records per request) you should be able to get at all of this data within a couple of hours. I suspect you lack reliable transformation tools to take github metadata and convert it to gitea versus the limitations of GitHub.

Thanks, yeah. We have started to look at that alternative endpoint, but it doesn't have the exact data as the api, nor is it always in the exact same format.

Although as I have run the migration myself several times to attempt to debug issues, it takes over 24hours due to ratelimiting.

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

Create more GitHub Apps. If you're hitting rate limits you can double your capacity by adding a new app and using round robin to cycle through requests/tokens. If you're using a PAT, you only have 5k requests and will bottleneck quickly.

I.... uhh... can't say I tried that... as it's against the TOS... cough All joking aside, they have banned accounts from other projects attempting to do the same, so if I were to do that (and I'm not saying that I would), I'd want to make sure that the exporter is solid prior to risking any account.

It's not against the TOS, the documentation is very clear:

  "Keep these ideas in mind when creating GitHub Apps:

  - A user or organization can own up to 100 GitHub Apps."

https://docs.github.com/en/developers/apps/getting-started-w...

Which is 1.5 million API requests per org per hour.

Gitea really really really looks like github.

I use it at home and for projects with a closed user group. It does everything we need, including CI (I have Drone setup). Very, very, very good for such a small binary.

Looking forwards to gitea Actions, Drone can fall apart in advanced workloads.

> The Git repositories have changed location.

> The development branch is now named main instead of master.

If only we could avoid such pointless downstream-affecting changes. Cool URI's shouldn't change. We have the technology. And doing such changes to satisfy manufactured outrage is even more sad.

Did they consider moving to gitlab?

Yup, it was one of the candidates. https://devtalk.blender.org/t/developer-blender-org-call-for...

Great news for self hosting and not sitting on and going all in on unreliable services like GitHub.

This is a consolidation of the self-hosting ecosystem because Phabricator is ending support. It's not terrible but I wouldn't call it good let alone great news.

Reply on news.ycombinator.com