Retiring Phabricator - Migrating tasks to Gitlab
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
Retirement of IRC Services and KDETalk.net (Jabber)
Hi all, For some time now, the level of use of our IRC services - notably being Pursuivant and the Telegram Matterbridge, but also including sKreamer - has been on the decline. I'd therefore like to permanently retire all three of these services. Depending on the level of community interest, we may opt to retain pursuivant however i'd like for it to be rebuilt as a Matrix native service rather than being a continuation of our existing irker based bot that occasionally has issues and falls off. Given that we are now fairly well migrated to Matrix, the need to maintain our Telegram bridging is much reduced, and i'd therefore like to retire that without replacement. In terms of sKreamer, it's primary utility has been to provide announcements of Forum posts and bugbot services. With Matrix providing site previews, and the Forum in imminent replacement by Discourse, both of these are no longer necessary - so i'd like to retire it without replacement as well. The only remaining service of contention here is the BNC, which has significantly less use now than it did many years ago - with only 30 active connections at the time of writing. It therefore appears to be of much less need than it was in years past, and i'd also like to retire it as well. Finally, many years ago (prior to my time in Sysadmin) we started providing Jabber services for the domains KDETalk.net and KDE.org. Due to abuse however, we have for a long time had to have registration on KDETalk.net disabled (KDE.org was always a manual registration). Much like the BNC, this appears to only have 19 active clients at the time of writing. As our official channel for chat is essentially Matrix now, I would like to retire this as well. Together, all of these retirements will allow us to retire one of our smaller DigitalOcean servers (the load all of these generate is computationally small and thus cheap, however they do occupy mental headspace that is better served focusing on other areas of our infrastructure). Comments on the above? Thanks, Ben
Re: Retiring Phabricator - Migrating tasks to Gitlab
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 >
Re: Retiring Phabricator - Migrating tasks to Gitlab
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 >> >
