Re: Information regarding upcoming Gitlab Migration
On Thu, Apr 30, 2020 at 4:17 AM Nicolás Alvarez wrote: > > > > El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt 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
Re: Information regarding upcoming Gitlab Migration
On Thu, Apr 30, 2020 at 6:16 AM Boudewijn Rempt wrote: > > On woensdag 29 april 2020 18:17:05 CEST Nicolás Alvarez wrote: > > > > My understanding is that there is a workboard per repository *and* another > > per group. > > > > Now, how big do we make the group workboard? All of KDE? A smaller > > category? That is the question. > > Ah, that makes more sense. I guess that there should be groups for > repositories that really fit together, like all the split-up pim stuff, and a > generic holding thing for the projects that are more on their own, like Krita > or Kdenlive. > Which is why we have proposed the structure that we have, because it allows for module level task boards, allows easy visibility of the merge requests related to the contained repositories, and makes projects contained within that group easy to list. Those projects that are standalone are put into groups based on what they're for (Krita = graphics, Kdenlive = multimedia) for ease of discoverability by those not familiar with them. Cheers, Ben > -- > https://www.valdyas.org | https://www.krita.orgh > > > >
Re: Information regarding upcoming Gitlab Migration
On woensdag 29 april 2020 18:17:05 CEST Nicolás Alvarez wrote: > > My understanding is that there is a workboard per repository *and* another > per group. > > Now, how big do we make the group workboard? All of KDE? A smaller category? > That is the question. Ah, that makes more sense. I guess that there should be groups for repositories that really fit together, like all the split-up pim stuff, and a generic holding thing for the projects that are more on their own, like Krita or Kdenlive. -- https://www.valdyas.org | https://www.krita.orgh
Re: Information regarding upcoming Gitlab Migration
Ok after a small chat with the Bhushan I learned that the plan is to use gitlab-triage instead of project labels. This should be way more powerful :D Sorry for the trouble Carl ‐‐‐ Original Message ‐‐‐ Le mercredi, avril 29, 2020 2:37 PM, Carl Schwan a écrit : > 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 gr...@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] > > publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Information regarding upcoming Gitlab Migration
> El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt 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. Now, how big do we make the group workboard? All of KDE? A smaller category? That is the question. -- Nicolas
Re: Information regarding upcoming Gitlab Migration
If your looking for an example of a project/repo level workboard look here. https://invent.kde.org/kde/kdiff3/-/boards. Just did a quick check this is indeed specific to kdiff3. Labels can also be created at this level. The board is completely customizable. On Wed, Apr 29, 2020, 11:21 AM Michael Reeves wrote: > > > On Wed, Apr 29, 2020, 10:19 AM Boudewijn Rempt wrote: > >> 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: >> > > Not sure what your referring to but kdiff3 has a workboard setup that is > not group level. I'll have another look at how this is setup. > > > >> > - 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. >> >> -- >> https://www.valdyas.org | https://www.krita.org >> >> >>
Re: Information regarding upcoming Gitlab Migration
On Wed, Apr 29, 2020, 10:19 AM Boudewijn Rempt wrote: > 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: > Not sure what your referring to but kdiff3 has a workboard setup that is not group level. I'll have another look at how this is setup. > > > - 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. > > -- > https://www.valdyas.org | https://www.krita.org > > >
Re: Information regarding upcoming Gitlab Migration
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 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] > publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Information regarding upcoming Gitlab Migration
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 (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] signature.asc Description: This is a digitally signed message part.
Re: Information regarding upcoming Gitlab Migration
On 2020 prilula d. 28id 13:35:22 CEST Ben Cooksley wrote: > Would some form of git alias/custom command script that works similar > to the following be suitable? > > git kde-clone skrooge > > That script would then search the appropriate groups (ignoring any > personal repositories including forks), find the necessary repository > and perform the clone as appropriate for you. Should it find multiple > results it would output it's results and then exit with a failure > (giving you names and the clone urls to pick from manually) That'd actually be pretty cool. As a standalone script it'd be useful to migrate existing checkouts, so that's shooting two birds in one foot. And then you can have a somewhat structured namespace, still with simple lookup and unstructured names (until, as Bhushan points out in a different message in this thread, you get non-unique labels when decomposing structures names). [ade] signature.asc Description: This is a digitally signed message part.
Information regarding upcoming Gitlab Migration: clarifications
Good afternoon, [Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] I want to clarify some bits for which we have gotten a questions about, - Non unique naming: There's some teams which prefer if we dropped the namespace- part from their name which we have added. While currently this does not result in the naming conflict right away, we realize this will cause it at one point, for example, maui-dialer -> maui/dialer plasma-dialer -> plasma-mobile/dialer To minimize the impact of the Gitlab move we won't be doing such renames which introduce non-unique names right away. But we would prefer if the existing tooling or infrastructure is ready for this kind of cases at later point. Only way to enforce non-unique naming is one big KDE/ subgroup which we want to avoid. Current naming in the repo-metadata branch[1] I've pointed does not reflect those renames, as we are not planning to do those renames right away during gitlab move, but at a later stage. - Existing configurations: we want to reduce impact on existing release schedule, and existing developer workflow, therefore we will continue to privide the existing anongit.kde.org and git.kde.org (although this will be read-only) with current flat structuring for 3 weeks after actual migration, which will keep the existing scripts/clones working enough to give developers time to change to the new structure. We will also try to provide a script which allows you to migrate your existing clones to new repo paths and as mentioned by Ben in other message, potentially a git-kde script which would allow you to clone individual repository without knowing it's namespace (provided that there is no conflict of it's name). like "git kde karchive" - Translations: we will co-ordinate with the translations team to let them adapt their tooling to updated structure as this requires changes on their side how translations are stored in svn repository Thanks! [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
