Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Thu, Apr 30, 2020 at 4:17 AM Nicolás Alvarez
<nicolas.alvarez at gmail.com> wrote:
>
>
> > El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt <boud at valdyas.org> escribió:
> >
> > On woensdag 29 april 2020 15:16:12 CEST Adriaan de Groot wrote:
> >>> 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 was **also** 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
> >
> > Outch, that's a nasty one. I thought there was a workboard per repository... And most of the proposed groups actually aren't really subcommunities in any case, just bags of holding for vaguely similar projects.
>
> My understanding is that there is a workboard per repository *and* another per group.
>

Correction: there is the possibility to do multiple workboards at the
project/repository level, which should suit most projects fine.

There is however a limitation of one workboard at the group level,
although it is anticipated that this should be sufficient for planning
and tracking for most grouped projects.

> Now, how big do we make the group workboard? All of KDE? A smaller category? That is the question.
>
> --
> Nicolas

Cheers,
Ben