Retiring Phabricator - Migrating tasks to Gitlab

Nate Graham nate at
Tue May 23 00:39:32 BST 2023

Great, this will be a good thing to have behind us.

Because workboards in GitLab are Label-driven via automation, I think we 
would have to make each workboard column in Phabricator transform into a 
custom label in GitLab so that Tasks' positions in workboards can be 
preserved when they move to GitLab.

Also, in Phabricator, Tasks have no real "home"; they just have project 
tags, and they can have multiple such tags to be able to belong to 
multiple projects. For example "VDG" and also "Plasma". Such a Task 
shows up in both projects' workboards. But in GitLab, Issues need to 
live in one place and only one place. So for such Phab tasks, we would 
need a way to determine the single new home of the Task in GitLab, and 
perhaps tag them with global-scope labels or something?

In Gitlab, it's Labels all the way down...


On 5/21/23 03:14, Ben Cooksley wrote:
> Hi all,
> As many of you will undoubtedly be aware, we currently have a bit of a 
> hybrid approach with our use of GitLab, with some projects/areas still 
> making use of Phabricator as they await the final import of these tasks 
> across to GitLab.
> That time has now arrived, as Phabricator is long since unmaintained and 
> needs to be retired.
> The only question is how this is best structured.
> My thinking on this had been to establish a mapping of Phabricator 
> project to Gitlab project (with some Gitlab projects possibly receiving 
> multiple Phabricator projects). Where necessary we would create 
> groups/projects under teams/ on <> 
> to house these, otherwise they'd be imported into the mainline projects.
> For those projects currently using GitLab as a task tracking tool, any 
> feedback you have on this would also be welcome.
> In terms of the migration, we'd be looking to retain as much information 
> as possible, however things like the precise column a task has on a 
> workboard would likely be lost. The actual content of the task including 
> details such as time and authorship, along with any comments would be 
> retained though.
> Thoughts?
> Thanks,
> Ben

More information about the kde-devel mailing list