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: Retirement of IRC Services and KDETalk.net (Jabber)

[Christian]

Am Montag, 22. Mai 2023, 10:24:48 CEST schrieb Ben Cooksley:

> > So instead of shuttering the service, I recommend that more attention
> > be drawn to it.
> 
> There are currently 114 people registered to use the BNC, so it appears to
> be rather well known among our community members.
> The decline in it's usage has correlated rather well with the rise of
> Matrix, so it appears that those that favour a BNC type experience find
> Matrix works just as well / better.

That seems more of a personal preference / your interpretation than fact, 
given that Halla wrote literally the opposite, to quote "we're still using irc 
in preference to matrix, since matrix is more complicated to use and not as 
reliable."

Other than that, given what Kenny wrote, given that IRC is still officially 
supported by KDE and was done so by a vote, personally I think we should offer 
the services necessary to improve the experience for KDE folks, given it's 
(znc, in this specific case) a very low cost service.

> Thanks,
> Ben

Kind regards, 

Christian

Re: Retirement of IRC Services and KDETalk.net (Jabber)

[Ben Cooksley]

On Mon, May 22, 2023 at 8:39 PM Vincent Pinon  wrote:

>
> Le 22/05/2023 à 10:24, Ben Cooksley a écrit :
>
> On Mon, May 22, 2023 at 10:05 AM argonel  wrote:
>
>> On Sun, May 21, 2023 at 3:12 PM Ben Cooksley  wrote:
>> >
>> > On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs) 
>> wrote:
>>
>> >> Bouncer wise: 30 connections isn't exactly none, especially if that
>> contains
>> >> active people. These would be forced to migrate to a service (and
>> register at
>> >> such) which is not under KDEs control and, as far as I am aware, has a
>> >> mandatory registration.  As far as memory serves some communities,
>> e.g. I
>> >> think krita, still had active devs / maintainers on IRC.
>> >
>> >
>> > Yes, there is a cost-benefit analysis to all services we run however -
>> and if there is a minimal number of people benefiting from it, sometimes it
>> is time to retire a service.
>> >
>> > Note that the 30 I quoted was a count of TCP connections - so included
>> inbound and outbound links.
>> > The number of connected clients is much, much smaller - so it is
>> possible there are some IRC connections still active for people that are no
>> longer around, or who have moved to Matrix and not deactivated the BNC.
>>
>> I would argue that the low usage is in part due to lack of awareness.
>> It has a one-line mention on the "Internet Relay Chat" community wiki
>> page (which wasn't added until 2019) that doesn't even explain the
>> benefits of using it.
>>
>> IRC in combination with the BNC is much more suited to intermittent
>> usage than Matrix is, which currently obligates the user to "be
>> active" every 30 days, or risk (permanently!) losing access to the
>> entirety of the history of all of their joined channels (even the
>> parts for which they were present). The BNC happily buffers the text
>> until your client is able to reconnect. As an example, this allowed me
>> to read discussions that happened while I endured an extended power
>> outage, even when Matrix had decided that I was idle for "too long".
>>
>
> Not sure what the bots do on the IRC side, but this kicking due to
> inactivity is actually due to IRC and the bridging between it and Matrix.
> It isn't an issue of Matrix itself as a protocol / software stack - it is
> a limitation imposed on the Matrix side to help Libera.chat with connection
> load.
>
>
>>
>> So instead of shuttering the service, I recommend that more attention
>> be drawn to it.
>>
>
> There are currently 114 people registered to use the BNC, so it appears to
> be rather well known among our community members.
> The decline in it's usage has correlated rather well with the rise of
> Matrix, so it appears that those that favour a BNC type experience find
> Matrix works just as well / better.
>
> Thanks,
> Ben
>
> Hello,
>
> This conversation made me realize I still had BNC activated for my
> account, despite not connecting to IRC anymore for long (and to matrix
> neither recently, my participation is rather on pause for the moment).
>
> It is not clear on the BNC UI, nor on community wiki, how to close the
> account. I just unregistered libera from BNC, but don't see how to
> completely close the service for me?
>
> Thanks again for taking care of all these services!
>

You're not able to remove your own BNC account - please file a ticket and
we'll action that.


> Vincent
>

Cheers,
Ben

Re: Retirement of IRC Services and KDETalk.net (Jabber)

[Vincent Pinon]

Le 22/05/2023 à 10:24, Ben Cooksley a écrit :

On Mon, May 22, 2023 at 10:05 AM argonel  wrote:

On Sun, May 21, 2023 at 3:12 PM Ben Cooksley 
wrote:
>
> On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs)
 wrote:

>> Bouncer wise: 30 connections isn't exactly none, especially if
that contains
>> active people. These would be forced to migrate to a service
(and register at
>> such) which is not under KDEs control and, as far as I am
aware, has a
>> mandatory registration.  As far as memory serves some
communities, e.g. I
>> think krita, still had active devs / maintainers on IRC.
>
>
> Yes, there is a cost-benefit analysis to all services we run
however - and if there is a minimal number of people benefiting
from it, sometimes it is time to retire a service.
>
> Note that the 30 I quoted was a count of TCP connections - so
included inbound and outbound links.
> The number of connected clients is much, much smaller - so it is
possible there are some IRC connections still active for people
that are no longer around, or who have moved to Matrix and not
deactivated the BNC.

I would argue that the low usage is in part due to lack of awareness.
It has a one-line mention on the "Internet Relay Chat" community wiki
page (which wasn't added until 2019) that doesn't even explain the
benefits of using it.

IRC in combination with the BNC is much more suited to intermittent
usage than Matrix is, which currently obligates the user to "be
active" every 30 days, or risk (permanently!) losing access to the
entirety of the history of all of their joined channels (even the
parts for which they were present). The BNC happily buffers the text
until your client is able to reconnect. As an example, this allowed me
to read discussions that happened while I endured an extended power
outage, even when Matrix had decided that I was idle for "too long".


Not sure what the bots do on the IRC side, but this kicking due to 
inactivity is actually due to IRC and the bridging between it and Matrix.
It isn't an issue of Matrix itself as a protocol / software stack - it 
is a limitation imposed on the Matrix side to help Libera.chat with 
connection load.



So instead of shuttering the service, I recommend that more attention
be drawn to it.


There are currently 114 people registered to use the BNC, so 
it appears to be rather well known among our community members.
The decline in it's usage has correlated rather well with the rise of 
Matrix, so it appears that those that favour a BNC type experience 
find Matrix works just as well / better.


Thanks,
Ben


Hello,

This conversation made me realize I still had BNC activated for my 
account, despite not connecting to IRC anymore for long (and to matrix 
neither recently, my participation is rather on pause for the moment).


It is not clear on the BNC UI, nor on community wiki, how to close the 
account. I just unregistered libera from BNC, but don't see how to 
completely close the service for me?


Thanks again for taking care of all these services!

Vincent

Re: Retirement of IRC Services and KDETalk.net (Jabber)

[Ben Cooksley]

On Mon, May 22, 2023 at 10:05 AM argonel  wrote:

> On Sun, May 21, 2023 at 3:12 PM Ben Cooksley  wrote:
> >
> > On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs) 
> wrote:
>
> >> Bouncer wise: 30 connections isn't exactly none, especially if that
> contains
> >> active people. These would be forced to migrate to a service (and
> register at
> >> such) which is not under KDEs control and, as far as I am aware, has a
> >> mandatory registration.  As far as memory serves some communities, e.g.
> I
> >> think krita, still had active devs / maintainers on IRC.
> >
> >
> > Yes, there is a cost-benefit analysis to all services we run however -
> and if there is a minimal number of people benefiting from it, sometimes it
> is time to retire a service.
> >
> > Note that the 30 I quoted was a count of TCP connections - so included
> inbound and outbound links.
> > The number of connected clients is much, much smaller - so it is
> possible there are some IRC connections still active for people that are no
> longer around, or who have moved to Matrix and not deactivated the BNC.
>
> I would argue that the low usage is in part due to lack of awareness.
> It has a one-line mention on the "Internet Relay Chat" community wiki
> page (which wasn't added until 2019) that doesn't even explain the
> benefits of using it.
>
> IRC in combination with the BNC is much more suited to intermittent
> usage than Matrix is, which currently obligates the user to "be
> active" every 30 days, or risk (permanently!) losing access to the
> entirety of the history of all of their joined channels (even the
> parts for which they were present). The BNC happily buffers the text
> until your client is able to reconnect. As an example, this allowed me
> to read discussions that happened while I endured an extended power
> outage, even when Matrix had decided that I was idle for "too long".
>

Not sure what the bots do on the IRC side, but this kicking due to
inactivity is actually due to IRC and the bridging between it and Matrix.
It isn't an issue of Matrix itself as a protocol / software stack - it is a
limitation imposed on the Matrix side to help Libera.chat with connection
load.


>
> So instead of shuttering the service, I recommend that more attention
> be drawn to it.
>

There are currently 114 people registered to use the BNC, so it appears to
be rather well known among our community members.
The decline in it's usage has correlated rather well with the rise of
Matrix, so it appears that those that favour a BNC type experience find
Matrix works just as well / better.

Thanks,
Ben