[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Information regarding upcoming Gitlab Migration
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2020-04-29 19:46:22
Message-ID: CA+XidOHx=DwNN28arWqH8UbKyvCZVuDwv6pNq-N=6LNi_dGvUA () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 30, 2020 at 4:17 AM Nicol=C3=A1s Alvarez
<nicolas.alvarez@gmail.com> wrote:
>
>
> > El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt <boud@valdyas.org> escr=
ibi=C3=B3:
> >
> > =EF=BB=BFOn 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 previo=
us
> >>> emails.
> >>
> >>
> >> Your mention of namespaces reminds me that there was **also** a discus=
sion 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 numbe=
r 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 reposito=
ry... 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* anothe=
r 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 catego=
ry? That is the question.
>
> --
> Nicolas

Cheers,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]