Retiring Phabricator - Migrating tasks to Gitlab
Nate Graham
nate at kde.org
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...
Nate
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 invent.kde.org <http://invent.kde.org>
> 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