DevOps, Phabricator & GitLab

Hi, iirc at some point there was talks about moving the development from Phabricator to a custom GitLab instance in the long term.

Have there been any experiments or any further discussions made in that direction?

IMO the modern UI, the merge request based workflow (instead of patches + Arcanist) and better CI tools could be great for getting more community patches.
Another benefit I could see is that in GitLab different projects / repositories are much more obviously seperated than on Phabricator, while at the same time having the issue tracking next to the code.
So if I wanted to check out the code for the Blender.org website I could just open that project - and if I found a spelling mistake, submitting a merge request with a fix could be done completely through the GitLab UI, without even having to touch Git.

Edit: Just checked and it seems that KDE is migrating from Phabricator to GitLab (they mostly seem to be done). I’d be surprised if there isn’t any documentation on this, maybe even some scripts or talks with more info

2 Likes

Even the Linux kernel (gfx) is seriously considering moving on gitlab :slight_smile:

https://lists.blender.org/pipermail/bf-committers/2022-January/051275.html

3 Likes

Are there other choices than gitlab and gerrit?
I suppose that atlassian, perforce, all those proprietary platforms are not even to be considered.

Gitea is/was also under consideration
some more discussion at The Bf-committers June 2021 Archive by thread

2 Likes

Jumping in on this thread; sorry for the delay.

A head’s up on this is in order.
I’ve been asked to be responsible for moving Blender from using Phabricator to instead use $something_else. This, together with a few other tasks , is the focus of my job at the studio, where I started on the 17th of jan.

It was clear quite early on that the choice involved has quite some impact in how it does or doesnt fit with blender’s core goals and ideals.

Ideally, the choice of software used for developing blender would, itself, adhere and align with the wish to provide open-source tooling, freely available to everyone to re-use and extend.

The mail from Ton on the BF-committers thread (linked above) explains that eloquently.

It is true for Gitlab that it is free to use, but only to a certain extent. You can self-host it with the Community Edition, but it lacks a number of features at that point that potentially make its use for the blender-studio something we’re looking into at the moment.

Above, Gitea is being mentioned, and indeed, it’s being looked at as an option. Obviously, it presents different challenges, different considerations.

There are some others also, like Pagure (Fedora/Centos) which seem to work for certain dev-teams as well. For that reason, they are also looked at.

Developments in this area are expected to speed up in the coming month(s) as it is clear we’re at a point what kind of short-list is out there to consider at all, and what choices we have available.

The choice of what software to go to is only one part of the equation however; we do not just want something to be a replacement, but also be an improvement in the features it provides as well as the process of working together on code , across the internet, as a community.

Last week, I sent a short intro about myself to bf-committers and invited people to reach out in case they have helpful considerations, tips or know about useful resources/threads/etc we should know about.

More news about this should, hopefully, not take another six months. It’s too important for that. But help and comments are very much appreciated.

Cheers

11 Likes

Here are lists of (Gitea and Gitlab) features and also differences between other Git hosting options:

Also:

If there is a list with things the new platform should support, this would probably belong:

https://devtalk.blender.org/t/proposal-introduce-a-dev-curfew-on-open-patches/15568/155

Best to continue this in the larger thread over at