<div dir="ltr"><div dir="ltr">On Tue, May 23, 2023 at 11:39 AM Nate Graham <<a href="mailto:nate@kde.org">nate@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Great, this will be a good thing to have behind us.<br></blockquote><div><br></div><div>You can say that again. </div><div><br></div><div>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. </div><div>Along with it being unmaintained, i'll be very happy to archive it and shutdown that container.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Because workboards in GitLab are Label-driven via automation, I think we <br>
would have to make each workboard column in Phabricator transform into a <br>
custom label in GitLab so that Tasks' positions in workboards can be <br>
preserved when they move to GitLab.<br></blockquote><div><br></div><div>This aligns with what Johnny has mentioned and seems reasonable enough to me.</div><div>In theory it shouldn't be too hard to automate.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, in Phabricator, Tasks have no real "home"; they just have project <br>
tags, and they can have multiple such tags to be able to belong to <br>
multiple projects. For example "VDG" and also "Plasma". Such a Task <br>
shows up in both projects' workboards. But in GitLab, Issues need to <br>
live in one place and only one place. So for such Phab tasks, we would <br>
need a way to determine the single new home of the Task in GitLab, and <br>
perhaps tag them with global-scope labels or something?<br></blockquote><div><br></div><div>Yes, we would need to do a deconflicting process there.</div><div>Any thoughts on the best approach to that? <br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In Gitlab, it's Labels all the way down...<br></blockquote><div><br></div><div>Yes :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Nate<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 5/21/23 03:14, Ben Cooksley wrote:<br>
> Hi all,<br>
> <br>
> As many of you will undoubtedly be aware, we currently have a bit of a <br>
> hybrid approach with our use of GitLab, with some projects/areas still <br>
> making use of Phabricator as they await the final import of these tasks <br>
> across to GitLab.<br>
> <br>
> That time has now arrived, as Phabricator is long since unmaintained and <br>
> needs to be retired.<br>
> <br>
> The only question is how this is best structured.<br>
> <br>
> My thinking on this had been to establish a mapping of Phabricator <br>
> project to Gitlab project (with some Gitlab projects possibly receiving <br>
> multiple Phabricator projects). Where necessary we would create <br>
> groups/projects under teams/ on <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a> <<a href="http://invent.kde.org" rel="noreferrer" target="_blank">http://invent.kde.org</a>> <br>
> to house these, otherwise they'd be imported into the mainline projects.<br>
> <br>
> For those projects currently using GitLab as a task tracking tool, any <br>
> feedback you have on this would also be welcome.<br>
> <br>
> In terms of the migration, we'd be looking to retain as much information <br>
> as possible, however things like the precise column a task has on a <br>
> workboard would likely be lost. The actual content of the task including <br>
> details such as time and authorship, along with any comments would be <br>
> retained though.<br>
> <br>
> Thoughts?<br>
> <br>
> Thanks,<br>
> Ben<br>
</blockquote></div></div>