Re: Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Mon, May 29, 2023 at 1:29 AM Johannes Zarl-Zierl 
wrote:

> Am Samstag, 27. Mai 2023, 23:13:08 CEST schrieb Ben Cooksley:
> > On Sun, May 28, 2023 at 8:24 AM Johannes Zarl-Zierl <
> johan...@zarl-zierl.at>
> > wrote:
> > > I'm fine with having columns be mapped as labels.
> > > However, if it is easy to implement, having some columns be converted
> to
> > > milestones would be quite nice, since we have been using columns to
> track
> > > tasks related to our releases.
> >
> > I haven't started looking into the full detail of what is needed to bring
> > detail across yet, however I imagine that may require a degree of extra
> > work.
> > I'll comment more on this once i've examined the Gitlab and Phabricator
> > APIs I need to work with to do the data migration.
>
> If it helps, I can also do some manual cleanup on kphotoalbum after the
> migration. If we're the only affected project, it is probably a better
> investment of time for me to assigne ~40 issues to milestones than it is
> for
> you to develop an automated migration script...
>

Noted. Based on what i'm seeing so far (i'm looking into the bztogl tool,
which was developed for the FDO move to Gitlab) this may end up being what
we need to do.


>
> Cheers,
>   Johannes
>

Cheers,
Ben

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Johannes Zarl-Zierl]

Am Samstag, 27. Mai 2023, 23:13:08 CEST schrieb Ben Cooksley:
> On Sun, May 28, 2023 at 8:24 AM Johannes Zarl-Zierl 
> wrote:
> > I'm fine with having columns be mapped as labels.
> > However, if it is easy to implement, having some columns be converted to
> > milestones would be quite nice, since we have been using columns to track
> > tasks related to our releases.
> 
> I haven't started looking into the full detail of what is needed to bring
> detail across yet, however I imagine that may require a degree of extra
> work.
> I'll comment more on this once i've examined the Gitlab and Phabricator
> APIs I need to work with to do the data migration.

If it helps, I can also do some manual cleanup on kphotoalbum after the 
migration. If we're the only affected project, it is probably a better 
investment of time for me to assigne ~40 issues to milestones than it is for 
you to develop an automated migration script...

Cheers,
  Johannes

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Sun, May 28, 2023 at 8:24 AM Johannes Zarl-Zierl 
wrote:

> That's great news!
>
> Am Montag, 22. Mai 2023, 17:17:50 CEST schrieb Wolthera:
> > Overall, I've noticed that milestones are best for collecting tasks
> > related to a release or a defined project (Say, a new tool, importer
> > or workflow), while the boards are better for if you need to track the
> > state of multiple issues, because Gitlab Free doesn't allow filtering
> > of issues on a board (only having columns for a specific issue label),
> > which effectively makes it a different UI for the issue list. Because
> > the board columns map to a label, it makes sense to have columns be
> > converted to labels for the vast majority of projects, yes.
>
> I'm fine with having columns be mapped as labels.
> However, if it is easy to implement, having some columns be converted to
> milestones would be quite nice, since we have been using columns to track
> tasks related to our releases.
>

I haven't started looking into the full detail of what is needed to bring
detail across yet, however I imagine that may require a degree of extra
work.
I'll comment more on this once i've examined the Gitlab and Phabricator
APIs I need to work with to do the data migration.


>
> Cheers,
>   Johannes
>

Cheers,
Ben

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Johannes Zarl-Zierl]

That's great news!

Am Montag, 22. Mai 2023, 17:17:50 CEST schrieb Wolthera:
> Overall, I've noticed that milestones are best for collecting tasks
> related to a release or a defined project (Say, a new tool, importer
> or workflow), while the boards are better for if you need to track the
> state of multiple issues, because Gitlab Free doesn't allow filtering
> of issues on a board (only having columns for a specific issue label),
> which effectively makes it a different UI for the issue list. Because
> the board columns map to a label, it makes sense to have columns be
> converted to labels for the vast majority of projects, yes.

I'm fine with having columns be mapped as labels.
However, if it is easy to implement, having some columns be converted to 
milestones would be quite nice, since we have been using columns to track 
tasks related to our releases.

Cheers,
  Johannes

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Michael Reeves]

What's the plan for sys admin tickets currently needed to publish releases?

May 26, 2023 5:10:43 PM Ben Cooksley :

> On Fri, May 26, 2023 at 9:31 AM Nate Graham  wrote:
>> On 5/23/23 03:48, Ben Cooksley wrote:>     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?
>> 
>> At least in the case where a Task is tagged with VDG and also something
>> else, it probably makes sense to have it live on GitLab in the
>> "something else" project/group/etc. Back in the Phab days, we used to
>> tag everything VDG-relevant with the VDG tag, but on Gitlab it probably
>> makes more sense to just CC the "@teams/vdg" group instead.
> 
> Excellent, sounds like we've got a path forward then.
> 
> I will look at publishing a list of projects this weekend (separate thread) 
> so people can nominate the project that should receive those issues.
> Note that if existing projects don't really fit (because it is for a 
> collection of projects) we may want to consider use of something like was 
> setup for KF6 (https://invent.kde.org/teams/frameworks-devs/kf6-workboard for 
> instance)
>  
>> 
>> Nate
> 
> Cheers,
> Ben


signature.asc
Description: PGP signature

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Fri, May 26, 2023 at 9:31 AM Nate Graham  wrote:

> On 5/23/23 03:48, Ben Cooksley wrote:> 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?
>
> At least in the case where a Task is tagged with VDG and also something
> else, it probably makes sense to have it live on GitLab in the
> "something else" project/group/etc. Back in the Phab days, we used to
> tag everything VDG-relevant with the VDG tag, but on Gitlab it probably
> makes more sense to just CC the "@teams/vdg" group instead.
>

Excellent, sounds like we've got a path forward then.

I will look at publishing a list of projects this weekend (separate thread)
so people can nominate the project that should receive those issues.
Note that if existing projects don't really fit (because it is for a
collection of projects) we may want to consider use of something like was
setup for KF6 (https://invent.kde.org/teams/frameworks-devs/kf6-workboard
for instance)


>
> Nate
>

Cheers,
Ben

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Nate Graham]

On 5/23/23 03:48, Ben Cooksley wrote:> 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?


At least in the case where a Task is tagged with VDG and also something 
else, it probably makes sense to have it live on GitLab in the 
"something else" project/group/etc. Back in the Phab days, we used to 
tag everything VDG-relevant with the VDG tag, but on Gitlab it probably 
makes more sense to just CC the "@teams/vdg" group instead.


Nate

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Tue, May 23, 2023 at 11:39 AM Nate Graham  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 
> > 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
>

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Nate Graham]

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

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Wolthera]

Great, pretty excited for the tasks to move to issues :)

On Sun, May 21, 2023 at 9:01 PM Ben Cooksley  wrote:
>
> On Sun, May 21, 2023 at 10:10 PM Johnny Jazeix  wrote:
>>
>>
>> Also, some phabricator tasks have hierarchy, is there an equivalent in 
>> gitlab? There are tasks in gitlab too but I'm not sure it is always the 
>> equivalent.
>
>
> Gitlab tasks can be related/linked together (and this can hopefully be 
> brought across), however they cannot be flagged as blocking/being blocked by 
> other tasks.
> The functionality to create a task hierarchy through blocked relationships is 
> only available in Gitlab EE.
>

Gitlab Free (that invent uses) also has the difference between
'Issues' and 'Tasks', the former being the equivalent to Phab tasks,
the latter being intended as an atomic subtask, which allows for one
level of dependency. On top of that, gitlab keeps tack of checklists
in the UI, so some minor amount of hierarchy is possible.

Overall, I've noticed that milestones are best for collecting tasks
related to a release or a defined project (Say, a new tool, importer
or workflow), while the boards are better for if you need to track the
state of multiple issues, because Gitlab Free doesn't allow filtering
of issues on a board (only having columns for a specific issue label),
which effectively makes it a different UI for the issue list. Because
the board columns map to a label, it makes sense to have columns be
converted to labels for the vast majority of projects, yes.

>>
>>
>> Cheers,
>>
>> Johnny
>
>
> Thanks,
> Ben




--
Wolthera

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Sun, May 21, 2023 at 10:10 PM Johnny Jazeix  wrote:

> Hi,
> Le dim. 21 mai 2023 à 11:15, Ben Cooksley  a écrit :
>
>> 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 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.
>>
>>
> Would there be a way to convert some columns as labels? For example, we
> have columns "Junior Jobs" that would be nice to have as a label.
>

We could probably bring the column names across as labels yes.


> Also, some phabricator tasks have hierarchy, is there an equivalent in
> gitlab? There are tasks in gitlab too but I'm not sure it is always the
> equivalent.
>

Gitlab tasks can be related/linked together (and this can hopefully be
brought across), however they cannot be flagged as blocking/being blocked
by other tasks.
The functionality to create a task hierarchy through blocked relationships
is only available in Gitlab EE.


>
> Cheers,
>
> Johnny
>

Thanks,
Ben


>
>
>> Thoughts?
>>
>> Thanks,
>> Ben
>>
>

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Halla Rempt]

On zondag 21 mei 2023 11:14:46 CEST Ben Cooksley wrote:
> 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.

Workboards aren't really important for us -- we tried to use them, but always 
messed up :-). Just the tasks and the comments on a task would be enough for 
Krita.

Halla

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Johnny Jazeix]

Hi,
Le dim. 21 mai 2023 à 11:15, Ben Cooksley  a écrit :

> 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 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.
>
>
Would there be a way to convert some columns as labels? For example, we
have columns "Junior Jobs" that would be nice to have as a label.
Also, some phabricator tasks have hierarchy, is there an equivalent in
gitlab? There are tasks in gitlab too but I'm not sure it is always the
equivalent.

Cheers,

Johnny


> Thoughts?
>
> Thanks,
> Ben
>

Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

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