Information regarding upcoming Gitlab Migration

[Carl Schwan]

Hi Sysadmins,

since we are speaking about workboard for groups, what is the plan for groups that don't work on a single project but on all of the KDE projects (e.g. VDG, documentation, localization, websites)?

I experimented a bit with project tags (https://invent.kde.org/groups/kde/-/labels). This would allow subscribing to only a certain sort of issue and code review. The problem with project tags is that it only works if all the projects share the same root (e.g kde) but we can still have a hierarchy kde/graphics, kde/plasma, kde/frameworks.

This is already a problem since at the moment there is no way to ping VDG and/or Promo in a merge request concerning the websites. I guess it is fine for KDE Web because we are a small group and I can ask a review in Matrix/Telegram. But I'm not sure it will work well for VDG and Promo who are already bigger groups.

So maybe we should go with the option to go with namespaces having all the same root?

Sorry for complaining so late. I still think the GitLab migration is a good thing and there are more advantages than disadvantages in the migration. So if you think project tags are not the way to go and there is a better way, I will trust you.

Thank you sysadmins for all the works you are doing making KDE infrastructure better. :D

Cheers,
Carl

Le mercredi, avril 29, 2020 1:16 PM, Adriaan de Groot <groot at kde.org> a écrit :

> On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote:
> 

> > We have gotten a request for namespacing from projects on multiple
> > occassion, in cgit our workaround has always been that we prefix the
> > repo name with namespace- (i.e wikitolearn-courses-backend).
> > While this works out with our current workflow, it is not really
> > optimal. I've also mentioned various new contributor focused
> > requirements which lead us to this proposal for structuring in previous
> > emails.
> 

> Your mention of namespaces reminds me that there wasalso a discussion in
> this thread about workboards and reviews.
> 

> GitLab can have one workboard per group. So depending on how the
> categories / namespaces work out, we have choices in the overall number of
> workboards:
> 

> -   one big one (flat)
> -   one per (sub)group / namespace
>     

>     We should look at this as well. Arguments I've seen in this thread
>     

> -   one big one is unmanageably large
> -   (sub)communities have asked for smaller (split) workboards
> -   split workboards make it harder to work over group boundaries
> -   one big one allows moving reviews and tasks to where they belong
>     

>     (The last point is "because there are no group boundaries").
>     

>     From the sound of it (without re-reading this entire thread today) it's a
>     distinction between generalists and specialists and a good workflow depends on
>     what it is you're trying to coordinate (drat, another "it depends" issue).
>     

>     [ade]
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - carl at carlschwan.eu - 0x7F564CB5.asc
Type: application/pgp-keys
Size: 3196 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200429/fe2d80cf/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 823 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200429/fe2d80cf/attachment.sig>