Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Tue, May 23, 2023 at 11:39 AM Nate Graham <nate at kde.org> wrote:

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

You can say that again.

Phabricator is a bit of a nightmare to host - in large part because the
entire content of our Subversion repository is indexed in it's database,
which has resulted in it consuming ~400GB on disk.
Along with it being unmaintained, i'll be very happy to archive it and
shutdown that container.


> 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.
>

This aligns with what Johnny has mentioned and seems reasonable enough to
me.
In theory it shouldn't be too hard to automate.


>
> 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?
>

Yes, we would need to do a deconflicting process there.
Any thoughts on the best approach to that?

The simplest would be to consider some projects to be the natural "home"
for tasks (likely the app in question) while meta groups (such as VDG /
Windows / Flatpak / etc) would only get a task if it was the only project
on a task.


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

Yes :)


>
> Nate
>

Cheers,
Ben


>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230523/0576665c/attachment.htm>