Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Olivier,

On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote:
> >Because in order to search for something, you need to know it exists.
> >
> >If you are just casually browsing, then the search can't help you.
> 
> I don't think people casually browse our repos. What use case is more likely 
> to happen and do we want to support? 

We don't really want to discard use-cases just because it does not suit
our workflow. That is not how we are going to gain new contributors, we
should value each contribution, be it drive-by contribution, or focused
contribution towards one single project.

> Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia 
> section. After carefully reading the code of two applications and three libs 
> he starts contributing to Elisa. 
> 
> Use case 2 : While using her Ubuntu installation of Elisa / while reading on 
> reddit about Elisa, Jerry decides to try to contribute to this project/fix 
> this bug that itches her and searches for it in KDE's forge. 

Let me add a some more usecases, some of which I've been dealing with in
project I maintain.

Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma
Mobile applications source code

Use case 4 : Tom is a student in Germany and is interested in
contributing to wikitolearn, and he asks where can I find code of the
wikitolearn?

Suggestion offered by sysadmin team does not cater to one single
use-case, but offers a way to provide a solution to all 4 usecases. For
Plasma Mobile team or Wikitolearn team it would be much easier to refer
contributors to the https://invent.kde.org/plasma-mobile or
https://invent.kde.org/wikitolearn then tell them to go to
https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma
Mobile.

> On the other hand, I think the discussion about spotting open merge requests 
> (in a derived thread from this one) should be answered, being by relevant 
> tags, subgroups or whatever. 

(super personal note)

Ironically, Usecase 1 is how I started contributing to KDE 7 years back.
While I was inspired by battery monitor re-design in 4.11 release, I
wanted to work on "something" so I did literally browse through various
repositories to find something where my technical capabilities were
enough to work on [1]. Back then it was projects.kde.org (chiliproject
installation).

[1] https://blog.bshah.in/2013/09/01/hello-planet/

-- 
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

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Ingo,

On Mon, Apr 27, 2020 at 03:46:13PM +0200, Ingo Klöcker wrote:
> > > I'm sorry, but I don't think that this is solved by your proposal for the
> > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant
> > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in
> > > the same group. The same is true for any project which uses some
> > > frameworks, e.g. graphics and the imageformats framework or whatever
> > > group kate and kwrite are going to end up in and the ktexteditor
> > > framework.
> > 
> > This is something which can be easily solved by Gitlab, Gitlab offers a
> > solution where project can be shared with another group.
> > 
> > So e.g. sharing kcontacts with kdepim should be possible, then all merge
> > requests/issues from kcontacts would show up under pim as well.
> 
> Great. So we could put all repos into an "all" group (e.g. rename kde to all) 
> and then have every subcommunity decide for themselves which repos they want 
> to see in their group.

No, sadly this does not work, I just tested this,

I have two different groups here

- https://invent.kde.org/sysadmin/test/test1
- https://invent.kde.org/sysadmin/test/test2

test1 have a repo called foo under it, which is shared with the test2
group. When someone visits test2, they are not offered the list of the
shared repositories but they are instead offered the empty page. One
have to click on Shared repositories tab to actually see the list.

https://invent.kde.org/groups/sysadmin/test/test2/-/shared

This defeats the purpose of the creating subgroups (offering easy
reachability).

-- 
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

Re: Unused scratch/clones repositories cleanup

[Nicolás Alvarez]

El sáb., 25 de abr. de 2020 a la(s) 09:04, Bhushan Shah
(bs...@mykolab.com) escribió:
>
> Hello community,
>
> Curently there's about 1400 repositories in total under the, scratch/
> and clones/ namespace.
>
> https://cgit.kde.org/scratch/
> https://cgit.kde.org/clones/
>
> I am sure many people are using some of this repositories, but some are
> fairly inactive and unused. We would like to ask community members to
> go through their own personal repositories and clean-up the unused
> repositories. Instructions on how to delete or trash personal
> repositories can be found at:
>
> https://community.kde.org/Sysadmin/GitKdeOrgManual#Deleting_personal_repositories

It seems many people hit this error: note that the trash command needs
the repository name *without* the .git suffix.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Le 27 avril 2020 22:33:12 GMT+02:00, Ben Cooksley  a écrit :
>On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid 
>wrote:
>>
>> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va
>escriure:
>> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud
> wrote:
>> > >
>> > > Hi,
>> > >
>> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
>> > > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah 
>wrote:
>> > > > >
>> > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC
>for
>> > > > > replies]
>> > > > >
>> > > > > Hello Community members,
>> > > > >
>> > > > > In view of upcoming Gitlab migration, we sysadmin team wants
>to share
>> > > > > the recommended structuring for the repositories on Gitlab.
>> > > > >
>> > > > > We had multiple options,
>> > > > >
>> > > > > - Flat structure: In this option we would have everything
>under one
>> > > > > single namespace/group: https://invent.kde.org/kde/knetwalk
>> > > > > - Subgroups under top-level group: In this option we would
>have a groups
>> > > > > under KDE namespace:
>https://invent.kde.org/kde/games/knetwalk
>> > > > > - Groups at top level: In this option we would establish a
>series of
>> > > > > groups at the top level, e.g. 
>https://invent.kde.org/games/knetwalk
>> > > > >
>> > >
>> > > Thank you for having options and talking to us before
>implementing it.
>> > >
>> > > > > We have discussed this with small but representative group of
>> > > > > contributors or maintainers, and based on their suggestions,
>we
>> > > > > recommend that we go with option 3. Having sub-groups at top
>level will
>> > > > > allow us to,
>> > > > >
>> > > > > - Provides good visibility on all reviews, tasks and other
>items within
>> > > > > the groups/modules we define
>> > > > > - Provides improvements to discoverability of projects
>> > > > > - Makes it possible for groups of projects to establish a
>group level
>> > > > > task board should it fit their needs (for tracking a release
>for
>> > > > > instance)
>> > > > > - Makes the most semantic sense, as the ‘KDE’ top level group
>suggested
>> > > > > in option 2 is duplicative considering the Gitlab instance is
>under
>> > > > > kde.org.
>> > > > > - The discoverability of projects is maximised, as there is
>no need to
>> > > > > open the top level ‘KDE’ group before going into the
>subgroup.
>> > > > >
>> > > > > I've worked on draft "move" of the current set of the
>repositories in
>> > > > > their respective subgroups at the repo-metadata project's
>branch [1].
>> > > > > You can browse the directory structure to get idea of how
>final
>> > > > > structure on Gitlab would look like.
>> > > > >
>> > > > > If we don't have any objections we would like to implement
>this next
>> > > > > week and move projects to https://invent.kde.org.
>> > > > >
>> > > > > Thanks!
>> > > > > Bhushan for sysadmin team
>> > > > >
>> > > > > [1]
>https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>> > > >
>> > > > Does this mean that to clone it we'll have to go "git clone
>> > > > kde:games/knetwalk" or something along the lines?
>> > > >
>> > > > If that's the case I'd much prefer if we didn't do this, at the
>moment
>> > > > it's already uncomfortable for me to remember the URL for some
>of the
>> > > > repos (e.g. is it sysadmin/ or not?), this will only increase
>the
>> > > > problem and I personally don't see the advantage.
>> > > >
>> > > > e.g. Is okular graphics or office? Is gwenview plasma or
>graphics? Is
>> > > > krita graphics or its own thing?
>> > > >
>> > > > I really prefer when I don't have to guess this kind of things
>when
>> > > > fetching a repository.
>> > > >
>> > >
>> > > I 100% agree with Aleix and I think it would also be detrimental
>for discoverability, exactly for the examples Aleix just gave.
>> > >
>> > > We came back from this subgroups ideas some times ago : wiki
>pages were hard to find because hidden under layers of groups. The same
>was true for api documentations. Now everything is flat and I think
>it's easier to find.
>> > >
>> > > Another bad message could also be sent by this: instead of
>exposing Konsole or Ark as two applications under the KDE umbrella, it
>would look like Utils for KDE, bringing back the KDE Desktop idea
>(where every application is already store in a submenu).
>> > >
>> > > As someone wrote later, if I'm looking for a given application,
>there is always the search function...
>> >
>> > That requires that you know it exists. We have 1,043 mainline
>> > repositories at the moment, which translates to 53 pages of
>projects
>> > under a flat structure system.
>> > Reality is nobody is going to page through that looking for
>something.
>>
>> But they have gitlab search, don't they?
>
>They do yes.
>
>>
>> I mean it's the solution you told Aleix to figure out if Okular was
>inside graphics or okular.
>>
>> Why is search valid for one case and not for the other?
>
>Because in order to search for something, 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 3:40:01 CEST, Bhushan Shah va escriure:
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
> 
> Hello Community members,
> 
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
> 
> We had multiple options,
> 
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> 
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
> 
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
> 
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
> 
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.

Anything that breaks kde:$repo will break the release-tools used for the 
monthly releases done by the release service and the l10n scripty scripts.

If it ends up happening it would be good if such change is as far away as 
possible from a release so the scripts can be adapted timely and hopefully 
without mistakes.

Cheers,
  Albert

> 
> Thanks!
> Bhushan for sysadmin team
> 
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> 

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid  wrote:
>
> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> > wrote:
> > >
> > > Hi,
> > >
> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > > > >
> > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > > > replies]
> > > > >
> > > > > Hello Community members,
> > > > >
> > > > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > > > the recommended structuring for the repositories on Gitlab.
> > > > >
> > > > > We had multiple options,
> > > > >
> > > > > - Flat structure: In this option we would have everything under one
> > > > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > > > - Subgroups under top-level group: In this option we would have a 
> > > > > groups
> > > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > > > - Groups at top level: In this option we would establish a series of
> > > > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > > > >
> > >
> > > Thank you for having options and talking to us before implementing it.
> > >
> > > > > We have discussed this with small but representative group of
> > > > > contributors or maintainers, and based on their suggestions, we
> > > > > recommend that we go with option 3. Having sub-groups at top level 
> > > > > will
> > > > > allow us to,
> > > > >
> > > > > - Provides good visibility on all reviews, tasks and other items 
> > > > > within
> > > > > the groups/modules we define
> > > > > - Provides improvements to discoverability of projects
> > > > > - Makes it possible for groups of projects to establish a group level
> > > > > task board should it fit their needs (for tracking a release for
> > > > > instance)
> > > > > - Makes the most semantic sense, as the ‘KDE’ top level group 
> > > > > suggested
> > > > > in option 2 is duplicative considering the Gitlab instance is under
> > > > > kde.org.
> > > > > - The discoverability of projects is maximised, as there is no need to
> > > > > open the top level ‘KDE’ group before going into the subgroup.
> > > > >
> > > > > I've worked on draft "move" of the current set of the repositories in
> > > > > their respective subgroups at the repo-metadata project's branch [1].
> > > > > You can browse the directory structure to get idea of how final
> > > > > structure on Gitlab would look like.
> > > > >
> > > > > If we don't have any objections we would like to implement this next
> > > > > week and move projects to https://invent.kde.org.
> > > > >
> > > > > Thanks!
> > > > > Bhushan for sysadmin team
> > > > >
> > > > > [1] 
> > > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> > > >
> > > > Does this mean that to clone it we'll have to go "git clone
> > > > kde:games/knetwalk" or something along the lines?
> > > >
> > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > it's already uncomfortable for me to remember the URL for some of the
> > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > problem and I personally don't see the advantage.
> > > >
> > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > > krita graphics or its own thing?
> > > >
> > > > I really prefer when I don't have to guess this kind of things when
> > > > fetching a repository.
> > > >
> > >
> > > I 100% agree with Aleix and I think it would also be detrimental for 
> > > discoverability, exactly for the examples Aleix just gave.
> > >
> > > We came back from this subgroups ideas some times ago : wiki pages were 
> > > hard to find because hidden under layers of groups. The same was true for 
> > > api documentations. Now everything is flat and I think it's easier to 
> > > find.
> > >
> > > Another bad message could also be sent by this: instead of exposing 
> > > Konsole or Ark as two applications under the KDE umbrella, it would look 
> > > like Utils for KDE, bringing back the KDE Desktop idea (where every 
> > > application is already store in a submenu).
> > >
> > > As someone wrote later, if I'm looking for a given application, there is 
> > > always the search function...
> >
> > That requires that you know it exists. We have 1,043 mainline
> > repositories at the moment, which translates to 53 pages of projects
> > under a flat structure system.
> > Reality is nobody is going to page through that looking for something.
>
> But they have gitlab search, don't they?

They do yes.

>
> I mean it's the solution you told Aleix to figure out if Okular was inside 
> graphics or okular.
>
> Why is search valid for one case and not for the other?

Because in order to search for something, you need to know it exists.

If you are just casually browsing, then the search can't 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > > >
> > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > > replies]
> > > >
> > > > Hello Community members,
> > > >
> > > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > > the recommended structuring for the repositories on Gitlab.
> > > >
> > > > We had multiple options,
> > > >
> > > > - Flat structure: In this option we would have everything under one
> > > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > > - Subgroups under top-level group: In this option we would have a groups
> > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > > - Groups at top level: In this option we would establish a series of
> > > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > We have discussed this with small but representative group of
> > > > contributors or maintainers, and based on their suggestions, we
> > > > recommend that we go with option 3. Having sub-groups at top level will
> > > > allow us to,
> > > >
> > > > - Provides good visibility on all reviews, tasks and other items within
> > > > the groups/modules we define
> > > > - Provides improvements to discoverability of projects
> > > > - Makes it possible for groups of projects to establish a group level
> > > > task board should it fit their needs (for tracking a release for
> > > > instance)
> > > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > > > in option 2 is duplicative considering the Gitlab instance is under
> > > > kde.org.
> > > > - The discoverability of projects is maximised, as there is no need to
> > > > open the top level ‘KDE’ group before going into the subgroup.
> > > >
> > > > I've worked on draft "move" of the current set of the repositories in
> > > > their respective subgroups at the repo-metadata project's branch [1].
> > > > You can browse the directory structure to get idea of how final
> > > > structure on Gitlab would look like.
> > > >
> > > > If we don't have any objections we would like to implement this next
> > > > week and move projects to https://invent.kde.org.
> > > >
> > > > Thanks!
> > > > Bhushan for sysadmin team
> > > >
> > > > [1] 
> > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> > >
> > > Does this mean that to clone it we'll have to go "git clone
> > > kde:games/knetwalk" or something along the lines?
> > >
> > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > it's already uncomfortable for me to remember the URL for some of the
> > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > problem and I personally don't see the advantage.
> > >
> > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > krita graphics or its own thing?
> > >
> > > I really prefer when I don't have to guess this kind of things when
> > > fetching a repository.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.

But they have gitlab search, don't they?

I mean it's the solution you told Aleix to figure out if Okular was inside 
graphics or okular.

Why is search valid for one case and not for the other?

Cheers,
  Albert

> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.
> 
> >
> > Best regards,
> > Olivier
> > > Aleix
> >
> >
> 
> Cheers,
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va escriure:
> In part I am mostly re-iterating what Ben already mentioned in different
> messages.
> 
> On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> 
> Yes
> 
> [Rest of message is with sysadmin hat off and as a developer]
> 
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
> 
> I do agree that it maybe small inconvience, but let's be honest, most of
> us have been using kdesrc-build or some kind of automated tooling for
> building everything, apart from very rare case we never have to manually
> clone any of KDE repository, at least it is true for me personally. I am
> not sure about others.

Please let's refrain from saying things like "most of us have been using 
kdesrc-build" when you don't have any data to back that up.

Cheers,
  Albert

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 1:46 AM Nate Graham  wrote:
>
>
>
> On 4/27/20 4:38 AM, Aleix Pol wrote:
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
>
> Trying to categorize everything into a single group cannot succeed
> because many projects could logically belong to multiple groups (e.g
> plasma-framework is a framework that's a part of Plasma; Discover is an
> app that's a part of Plasma; kdenetwork-filesharing and kio-extras are
> libraries that are distributed via the apps release service). I foresee
> endless pointless arguments about the best group for something to live in.

Sorry, but I don't think that will be a problem in reality.
Historically, back in the Subversion era, we had no choice but to
assign things to modules
(multimedia/graphics/office/network/games/etc) and we made that work
without much in the way of problems.

>
> Let's step back: do we have to put every repo inside a group in the
> first place? Is it solely so you can look at a nice list of all open
> merge requests for PIM/Frameworks/etc? If so, perhaps this workflow
> could be approximated with tags instead or group assignments instead

Given the complaints we have had around Phabricator, I can assure you
that tags/labels will not work.

People won't understand them, and we will have discoverability issues
with them especially for newcomers.

>
> We create many very granular groups for the purposes of organizing teams
> and and performing code review (e.g. Plasma, KWin, Frameworks, PIM,
> Krita, Dolphin, Okular, VDG, etc.) and then every new merge request
> could receive a tag or assignee corresponding to its relevant code
> review groups (e.g. merge requests for kio and kio-extras could get get
> tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs
> could get tagged with both "Plasma" and "Frameworks", and so on).
>
> So +1 for a single top-level group I suppose.
>
> Nate

Regards,
Ben

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 12:04 AM Ingo Klöcker  wrote:
>
> On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> > That requires that you know it exists. We have 1,043 mainline
> > repositories at the moment, which translates to 53 pages of projects
> > under a flat structure system.
> > Reality is nobody is going to page through that looking for something.
>
> I have to disagree. Whenever I'm looking for a project I browse
> https://projects.kde.org/ (aka https://cgit.kde.org/).
> Using a simple Ctrl+F in my browser allowed me to find what I was looking for
> rather easily.

Sorry, but cgit.kde.org will be gone once we have moved to Gitlab.

>
> Having to look into *several* subgroups (because I guess we all know from
> experience that any categorization into several groups never matches our
> expectation) would have been a pain in the ass.
>

Also note that Gitlab search spans across group boundaries.

>
> > Please also see my point regarding listing merge requests at the group
> > level
>
> This argument only holds if the subgroups match development teams. It does
> already break down if e.g. a KDE PIM developer wants to see merge requests for
> PIM related frameworks and for PIM applications.
>

That is unfortunate, but you will never get a perfect solution.

> I have experienced exactly this problem at work were we have put repos of
> unrelated projects into different groups. It was extremely inconvenient that,
> while working on more than one project at the same time, I couldn't see all
> MRs I'm interested in on a single page.
>
> IMNSHO the groups in GitLab are not the right solution for gathering all repos
> some dev team, let alone individual devs, is/are interested in, because the
> assumption that different dev teams are interested in *disjoint* sets of repos
> is simply wrong. Moreover, the assumption that all members of some dev team
> are interested in exactly the same repos is equally wrong (even if most team
> members are probably interested in most of the same repos).
>
> And while the mapping group to dev team might make sense for something like
> plasma or frameworks or KDE PIM, I sure that it makes less or no sense for
> groups like graphics were different teams are working on different
> applications in the same group.
>
>
> > - you can see an example of what a flat structure ends up
> > looking like at https://gitlab.gnome.org/GNOME
> >
> > For those projects that span multiple repositories, you have just
> > denied them any chance or ability to see a listing of everything
> > related to their wider project.
>
> I'm sorry, but I don't think that this is solved by your proposal for the KDE
> PIM projects because not everything related to KDE PIM (e.g. relevant
> frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in the
> same group. The same is true for any project which uses some frameworks, e.g.
> graphics and the imageformats framework or whatever group kate and kwrite are
> going to end up in and the ktexteditor framework.
>
> The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to
> user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a single
> group is insufficient for us (while it's sufficient for most users of
> gitlab.com).
>
> Regards,
> Ingo

Regards,
Ben

Re: Information regarding upcoming Gitlab Migration

[Rolf Eike Beer]

Bhushan Shah wrote:


I've worked on draft "move" of the current set of the repositories in
their respective subgroups at the repo-metadata project's branch [1].
You can browse the directory structure to get idea of how final
structure on Gitlab would look like.


No objection, just a request for clarification: it looks like everything 
in extragear or playground was merged into there, right?


Eike

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde to all)
and then have every subcommunity decide for themselves which repos they want
to see in their group.


If this is possible, it seems like the best solution to me.

Nate

Re: Information regarding upcoming Gitlab Migration

[Johan Ouwerkerk]

On Mon, Apr 27, 2020 at 2:32 PM Piyush Aggarwal
 wrote:
>
> How long do redirects like this one work? If they will keep working 
> indefinitely, then maybe we can have all the repos at flat URLs for once and 
> then move them to respective subgroups?

I don't think this works if you want $repo to appear in *both* A and B
subgroups. A move is a one-way operation.

If I understand the docs [1] correctly then the multi-group thing is
mostly labeling with aliases in our case. There would be one KDE
structure and a bunch of groups which are basically an ACL with a name
to selectively grant access to a project via the "sharing" mechanism.
So projects in such a group are in fact aliases for projects in the
main KDE namespace similar to symlinks.

The trick is therefore basically: make everybody a member of every
group so you see $repo under both A and B groups because KDE/$repo is
shared from the KDE group with both A and B.

Regards,

- Johan

[1]: https://docs.gitlab.com/ee/user/group/

Re: Information regarding upcoming Gitlab Migration

[Johan Ouwerkerk]

On Mon, Apr 27, 2020 at 3:30 PM Luigi Toscano  wrote:
>
> Bhushan Shah ha scritto:
>
> > - But most importantly, this breaks with the non-unique leaf repository
> >   names feature offered by the proposed structure. So, There could be
> >   maui/documentation and wikitolearn/documentation. But we would have
> >   single KDE/documentation redirect
>
>
>
> Just to clarify: are we going towards a non-unique leaf repository name? I
> thought we were going to maintain the leaf uniqueness regardless.
>
> --
> Luigi

AFAIK `kdesrc-build` cannot cope wth non-unique repo names: it needs
$repo.git to be unique. In fact, things need to be slightly more
unique than just within the KDE namespace: names must also be unique
over the set of 3rd party names referenced in the dependency data (and
the other modules that a `kdesrc-build.rc` might refer to, but that is
also on the user).

So people had better avoid "common" names if they want their project
to build with `kdesrc-build` (or brush up their Perl 5 skills to fix
it).

I guess for most projects this won't matter too much, but I can
imagine how this could bite translations & related tooling as well.

Regards,

- Johan

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:52 AM, Nate Graham wrote:

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde 
to all)
and then have every subcommunity decide for themselves which repos 
they want

to see in their group.


If this is possible, it seems like the best solution to me.



I've just been informed that it's possible to have a project appear in 
multiple groups such that I could find plasma-frameworks in both the 
Frameworks and Plasma top-level groups.


Therefore I rescind my objection and endorse having many top-level 
groups instead of a single flat top-level namespace, provided that we do 
put projects that are related to multiple groups into those multiple groups.


Nate

Re: Information regarding upcoming Gitlab Migration

[Ingo Klöcker]

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:
> [adding sysad...@kde.org in CC, please make sure you keep it in CC]
> 
> On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker wrote:
> > On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> > > That requires that you know it exists. We have 1,043 mainline
> > > repositories at the moment, which translates to 53 pages of projects
> > > under a flat structure system.
> > > Reality is nobody is going to page through that looking for something.
> > 
> > I have to disagree. Whenever I'm looking for a project I browse
> > https://projects.kde.org/ (aka https://cgit.kde.org/).
> > Using a simple Ctrl+F in my browser allowed me to find what I was looking
> > for rather easily.
> > 
> > Having to look into *several* subgroups (because I guess we all know from
> > experience that any categorization into several groups never matches our
> > expectation) would have been a pain in the ass.
> > 
> > > Please also see my point regarding listing merge requests at the group
> > > level
> > 
> > This argument only holds if the subgroups match development teams. It does
> > already break down if e.g. a KDE PIM developer wants to see merge requests
> > for PIM related frameworks and for PIM applications.
> > 
> > I have experienced exactly this problem at work were we have put repos of
> > unrelated projects into different groups. It was extremely inconvenient
> > that, while working on more than one project at the same time, I couldn't
> > see all MRs I'm interested in on a single page.
> > 
> > IMNSHO the groups in GitLab are not the right solution for gathering all
> > repos some dev team, let alone individual devs, is/are interested in,
> > because the assumption that different dev teams are interested in
> > *disjoint* sets of repos is simply wrong. Moreover, the assumption that
> > all members of some dev team are interested in exactly the same repos is
> > equally wrong (even if most team members are probably interested in most
> > of the same repos).
> > 
> > And while the mapping group to dev team might make sense for something
> > like
> > plasma or frameworks or KDE PIM, I sure that it makes less or no sense for
> > groups like graphics were different teams are working on different
> > applications in the same group.
> > 
> > > - you can see an example of what a flat structure ends up
> > > looking like at https://gitlab.gnome.org/GNOME
> > > 
> > > For those projects that span multiple repositories, you have just
> > > denied them any chance or ability to see a listing of everything
> > > related to their wider project.
> > 
> > I'm sorry, but I don't think that this is solved by your proposal for the
> > KDE PIM projects because not everything related to KDE PIM (e.g. relevant
> > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in
> > the same group. The same is true for any project which uses some
> > frameworks, e.g. graphics and the imageformats framework or whatever
> > group kate and kwrite are going to end up in and the ktexteditor
> > framework.
> 
> This is something which can be easily solved by Gitlab, Gitlab offers a
> solution where project can be shared with another group.
> 
> So e.g. sharing kcontacts with kdepim should be possible, then all merge
> requests/issues from kcontacts would show up under pim as well.

Great. So we could put all repos into an "all" group (e.g. rename kde to all) 
and then have every subcommunity decide for themselves which repos they want 
to see in their group.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 4:38 AM, Aleix Pol wrote:

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?


Trying to categorize everything into a single group cannot succeed 
because many projects could logically belong to multiple groups (e.g 
plasma-framework is a framework that's a part of Plasma; Discover is an 
app that's a part of Plasma; kdenetwork-filesharing and kio-extras are 
libraries that are distributed via the apps release service). I foresee 
endless pointless arguments about the best group for something to live in.


Let's step back: do we have to put every repo inside a group in the 
first place? Is it solely so you can look at a nice list of all open 
merge requests for PIM/Frameworks/etc? If so, perhaps this workflow 
could be approximated with tags instead or group assignments instead


We create many very granular groups for the purposes of organizing teams 
and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, 
Krita, Dolphin, Okular, VDG, etc.) and then every new merge request 
could receive a tag or assignee corresponding to its relevant code 
review groups (e.g. merge requests for kio and kio-extras could get get 
tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs 
could get tagged with both "Plasma" and "Frameworks", and so on).


So +1 for a single top-level group I suppose.

Nate

Re: Information regarding upcoming Gitlab Migration

[Luigi Toscano]

Bhushan Shah ha scritto:

> - But most importantly, this breaks with the non-unique leaf repository
>   names feature offered by the proposed structure. So, There could be
>   maui/documentation and wikitolearn/documentation. But we would have
>   single KDE/documentation redirect



Just to clarify: are we going towards a non-unique leaf repository name? I
thought we were going to maintain the leaf uniqueness regardless.

If this is the case, I'd really like to express my disappointment: we are
basically forcing back the namespaces as part of the application name. Dolphin
is going to be referred to application/dolphin or application_dolphin, kstars
as education/kstars and so on, because we can have duplicates.

This is a huge step back, also because the namespaces are mixed: we have
subproject types (wikitolearn, maui, plasma-mobile) and category types
(education, pim, graphics, etc). What if plasma-mobile want to distinguish
their projects by categories? That's inconsistent.


We don't know where we will be in 10 years in terms of tooling, maybe gitlab
itself will  introduce better filtering capabilities, let's keep at least the
uniqueness of leaves.


I suspect we need some compromise decision (not win-win, sadly) here, but I
feel that having both (mixed) subcategories (non-flat) and no uniqueness of
repository names is going to be the worst combination.

-- 
Luigi

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

On Mon, Apr 27, 2020 at 06:02:19PM +0530, Piyush Aggarwal wrote:
> How long do redirects like this one work? If they will keep working
> indefinitely, then maybe we can have all the repos at flat URLs for once
> and then move them to respective subgroups? That way we will have access to
> our simple URLs through a redirect as I mentioned before, and also the
> ability to manage the Invent as recommended by sysadmins.

Documentation says that redirect will stay as long as original name is
not claimed by the new group, user or project.

However there's multiple problems with the workflow of moving something
to the KDE/ namespace first and then to respective group.

- There will be empty KDE/ group visible which would be confusing for
  visitors
- Workflow of the importing repository becomes complicated without any
  advantage IMO. For instance to import bshah/kframework into
  frameworks/ I've to first transfer it's ownership to KDE and then
  transfer it's ownership to frameworks/ group.
- But most importantly, this breaks with the non-unique leaf repository
  names feature offered by the proposed structure. So, There could be
  maui/documentation and wikitolearn/documentation. But we would have
  single KDE/documentation redirect

-- 
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

Re: Information regarding upcoming Gitlab Migration

[Piyush Aggarwal]

On Mon, 27 Apr, 2020, 5:57 pm Bhushan Shah,  wrote:

> Hello
>
> On Mon, Apr 27, 2020 at 02:10:11PM +0200, Boudewijn Rempt wrote:
> > On maandag 27 april 2020 03:40:01 CEST Bhushan Shah wrote:
> >
> > > [1]
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > Maybe it would make sense to keep a kde top-level group for some of the
> bigger projects that really don't fit in a category -- I don't think Krita
> fits in the graphics group, since we never ever do anything with any of the
> other repositories in that category.
>
> Slightly off-topic, but, in general idea is that we want to get away
> from the KDE is software, and more towards KDE is community and people,
> having a KDE/ namespace is step backward IMHO.
>
> > I have to admit, I also dread updating instructions and checkouts
> everywhere from invent.kde.org/kde/krita to invent.kde.org/graphics/krita.
> ..
>
> You don't really have to update the URL, since this project was already
> on invent.kde.org we would be doing a move, which would automatically
> add a redirect, so while if you want to update, it is fine, it won't be
> breaking any of existing links/setups.
>

How long do redirects like this one work? If they will keep working
indefinitely, then maybe we can have all the repos at flat URLs for once
and then move them to respective subgroups? That way we will have access to
our simple URLs through a redirect as I mentioned before, and also the
ability to manage the Invent as recommended by sysadmins.

Best
Piyush Aggarwal

Re: Information regarding upcoming Gitlab Migration

[Boudewijn Rempt]

On maandag 27 april 2020 14:26:16 CEST Bhushan Shah wrote:

> > I have to admit, I also dread updating instructions and checkouts 
> > everywhere from invent.kde.org/kde/krita to invent.kde.org/graphics/krita...
> 
> You don't really have to update the URL, since this project was already
> on invent.kde.org we would be doing a move, which would automatically
> add a redirect, so while if you want to update, it is fine, it won't be
> breaking any of existing links/setups.

Ah, then everything is fine :-)

-- 
https://www.krita.org

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hello

On Mon, Apr 27, 2020 at 02:10:11PM +0200, Boudewijn Rempt wrote:
> On maandag 27 april 2020 03:40:01 CEST Bhushan Shah wrote:
> 
> > [1] 
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> Maybe it would make sense to keep a kde top-level group for some of the 
> bigger projects that really don't fit in a category -- I don't think Krita 
> fits in the graphics group, since we never ever do anything with any of the 
> other repositories in that category.

Slightly off-topic, but, in general idea is that we want to get away
from the KDE is software, and more towards KDE is community and people,
having a KDE/ namespace is step backward IMHO.

> I have to admit, I also dread updating instructions and checkouts everywhere 
> from invent.kde.org/kde/krita to invent.kde.org/graphics/krita...

You don't really have to update the URL, since this project was already
on invent.kde.org we would be doing a move, which would automatically
add a redirect, so while if you want to update, it is fine, it won't be
breaking any of existing links/setups.

-- 
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

KDE's Feel-Good Bulletin, Issue #01

[Aniqa Khokhar]

Dear KDE Community Members,

It's official: You are amazing.

And you don't have to take it from me -- here are some of the more positive
reactions from users we have had this week:

--
" Finally, I found the best desktop environment for me. It's modern, highly
customizable and well optimized. @kdecommunity KDE Plasma is amazing!"

-- Juan José Quiroz O. on Twitter (https://twitter.com/juanjqo/status/
1252109821559668736)
--
"Thank you for all your work."

-- Vance W. on LinkedIn (https://www.linkedin.com/feed/update/urn:li:activity:
6659074456079613952?
commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6659074456079613952%2C6659399380723912704%29)
--
"The best desktop environment"

-- Claudio Grassi on LinkedIn (https://www.linkedin.com/feed/update/
urn:li:activity:6659074456079613952?
commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6659074456079613952%2C6659864226674290688%29)
--
"Marvelous! KDE is the world's digital treasure."

-- redboygoes2town on Reddit (https://www.reddit.com/r/kde/comments/g6mbc1/
dolphin_kdes_file_manager_improvements_gestures/fob5o0r/)
--
"sudo pacman -S kdenlive "

-- Radwan Programer on Facebook (https://www.facebook.com/kde/posts/
10157555246413918)
--

Regards,

Aniqa Khokhar
--
Promotion & Communication

www: http://kde.org
Mastodon: https://mastodon.technology/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

[adding sysad...@kde.org in CC, please make sure you keep it in CC]

On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker wrote:
> On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> > That requires that you know it exists. We have 1,043 mainline
> > repositories at the moment, which translates to 53 pages of projects
> > under a flat structure system.
> > Reality is nobody is going to page through that looking for something.
> 
> I have to disagree. Whenever I'm looking for a project I browse
> https://projects.kde.org/ (aka https://cgit.kde.org/).
> Using a simple Ctrl+F in my browser allowed me to find what I was looking for 
> rather easily.
> 
> Having to look into *several* subgroups (because I guess we all know from 
> experience that any categorization into several groups never matches our 
> expectation) would have been a pain in the ass.
> 
> 
> > Please also see my point regarding listing merge requests at the group
> > level
> 
> This argument only holds if the subgroups match development teams. It does 
> already break down if e.g. a KDE PIM developer wants to see merge requests 
> for 
> PIM related frameworks and for PIM applications.
> 
> I have experienced exactly this problem at work were we have put repos of 
> unrelated projects into different groups. It was extremely inconvenient that, 
> while working on more than one project at the same time, I couldn't see all 
> MRs I'm interested in on a single page.
> 
> IMNSHO the groups in GitLab are not the right solution for gathering all 
> repos 
> some dev team, let alone individual devs, is/are interested in, because the 
> assumption that different dev teams are interested in *disjoint* sets of 
> repos 
> is simply wrong. Moreover, the assumption that all members of some dev team 
> are interested in exactly the same repos is equally wrong (even if most team 
> members are probably interested in most of the same repos).
> 
> And while the mapping group to dev team might make sense for something like 
> plasma or frameworks or KDE PIM, I sure that it makes less or no sense for 
> groups like graphics were different teams are working on different 
> applications in the same group.
> 
> 
> > - you can see an example of what a flat structure ends up
> > looking like at https://gitlab.gnome.org/GNOME
> > 
> > For those projects that span multiple repositories, you have just
> > denied them any chance or ability to see a listing of everything
> > related to their wider project.
> 
> I'm sorry, but I don't think that this is solved by your proposal for the KDE 
> PIM projects because not everything related to KDE PIM (e.g. relevant 
> frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in the 
> same group. The same is true for any project which uses some frameworks, e.g. 
> graphics and the imageformats framework or whatever group kate and kwrite are 
> going to end up in and the ktexteditor framework.
> 

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.

> The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to 
> user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a 
> single 
> group is insufficient for us (while it's sufficient for most users of 
> gitlab.com).
> 
> Regards,
> Ingo



-- 
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

Re: Information regarding upcoming Gitlab Migration

[Ingo Klöcker]

On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.

I have to disagree. Whenever I'm looking for a project I browse
https://projects.kde.org/ (aka https://cgit.kde.org/).
Using a simple Ctrl+F in my browser allowed me to find what I was looking for 
rather easily.

Having to look into *several* subgroups (because I guess we all know from 
experience that any categorization into several groups never matches our 
expectation) would have been a pain in the ass.


> Please also see my point regarding listing merge requests at the group
> level

This argument only holds if the subgroups match development teams. It does 
already break down if e.g. a KDE PIM developer wants to see merge requests for 
PIM related frameworks and for PIM applications.

I have experienced exactly this problem at work were we have put repos of 
unrelated projects into different groups. It was extremely inconvenient that, 
while working on more than one project at the same time, I couldn't see all 
MRs I'm interested in on a single page.

IMNSHO the groups in GitLab are not the right solution for gathering all repos 
some dev team, let alone individual devs, is/are interested in, because the 
assumption that different dev teams are interested in *disjoint* sets of repos 
is simply wrong. Moreover, the assumption that all members of some dev team 
are interested in exactly the same repos is equally wrong (even if most team 
members are probably interested in most of the same repos).

And while the mapping group to dev team might make sense for something like 
plasma or frameworks or KDE PIM, I sure that it makes less or no sense for 
groups like graphics were different teams are working on different 
applications in the same group.


> - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.

I'm sorry, but I don't think that this is solved by your proposal for the KDE 
PIM projects because not everything related to KDE PIM (e.g. relevant 
frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in the 
same group. The same is true for any project which uses some frameworks, e.g. 
graphics and the imageformats framework or whatever group kate and kwrite are 
going to end up in and the ktexteditor framework.

The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to 
user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a single 
group is insufficient for us (while it's sufficient for most users of 
gitlab.com).

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

In part I am mostly re-iterating what Ben already mentioned in different
messages.

On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?

Yes

[Rest of message is with sysadmin hat off and as a developer]

> If that's the case I'd much prefer if we didn't do this, at the moment
> it's already uncomfortable for me to remember the URL for some of the
> repos (e.g. is it sysadmin/ or not?), this will only increase the
> problem and I personally don't see the advantage.

I do agree that it maybe small inconvience, but let's be honest, most of
us have been using kdesrc-build or some kind of automated tooling for
building everything, apart from very rare case we never have to manually
clone any of KDE repository, at least it is true for me personally. I am
not sure about others.

[Very non-scientific test, I did "history | grep 'git clone kde:'" on my
machine and only instances were 4, websites/conf-kde-in,
kde-build-metadata, sysadmin/irc-notifications,
sysadmin/binary-factory-tooling, rest was automatically downloaded by
the kdesrc-build]

Anyway, getting back on topic, while this option gives some initial
setbacks in our own personal workflow, let's look at bigger picture.

Let's say I am the new developer who wants to contribute to frameworks.
One of reason we are switching to gitlab is better onboarding, current
state is that we have cgit.kde.org as a repository browser.

By default I open it, I get the sorting by name, first repository is
abakus. Commits as old as 14 years(!), after that some more mix of
unmaintained repositories and scrolling almost 1.5 page, I get greeted
with baloo, first framework in whole list. Let's just assume that name
based sorting is bad idea, and we sort by activity instead.

Here I get much better results, first framework is solid. But at same
time if I was looking for SDK, kdevelop would appear at 3rd scroll-page.
Here cgit is able to show many items in single scroll page, you can be
assured that on gitlab it would not show kdevelop in first 6-7 pages.

You might wonder why search does not help here? So problem with search
is you need to know what you are looking for[*], but drive-by
contributors, or users who are simply browsing our repositories won't
know what they are looking for, they are simply trying to find a thing
that interests them. Giving them categories/groups allows them to focus
on topic they like and they can contribute to.

> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?

I agree that categories are something which we can improve upon, but
this is something which we can improve upon, rejecting idea of
categories just because 7-10 repos are at wrong place is ultimately not
going to do anything good.

> I really prefer when I don't have to guess this kind of things when
> fetching a repository.

[*] Ironically, in your case search would be helpful as you know you are
looking for knetwalk so you can just add it and search it

-- 
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

Re: Poll: Select Akademy 2020 training sessions

[Adam Szopa]

Dnia niedziela, 19 kwietnia 2020 23:06:00 CEST Adam Szopa pisze:
> Hi KDE community,
> I hope you've heard that Akademy 2020[1] is coming and marked the date in
> your calendars!
> During the event we'd like to have training sessions on topics that will
> help the KDE contributors the most. What will those topics be? Help us
> select them by answering our poll: https://survey.kde.org/521939[2] .
> It's a ranked list, so you can select as many topics as you want and put
> them in the order that works best for you.
> I cannot guarantee that every topic will have it's own training session, but
> on the other hand, popular ones might land a separate one outside of
> Akademy.
> 
> Stay safe,
> - Adam
> 
> 
> [1] https://akademy.kde.org/2020
> [2] https://survey.kde.org/521939

Hi,
Quick heads-up, the survey[1] is still open for a few days, so if you hadn't 
expressed your 
preferences yet - now's your chance!

- Adam


[1] https://survey.kde.org/521939

Re: Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Le lundi 27 avril 2020, 13:19:07 CEST Ben Cooksley a écrit :
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > > >
> > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > > replies]
> > > >
> > > > Hello Community members,
> > > >
> > > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > > the recommended structuring for the repositories on Gitlab.
> > > >
> > > > We had multiple options,
> > > >
> > > > - Flat structure: In this option we would have everything under one
> > > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > > - Subgroups under top-level group: In this option we would have a groups
> > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > > - Groups at top level: In this option we would establish a series of
> > > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > We have discussed this with small but representative group of
> > > > contributors or maintainers, and based on their suggestions, we
> > > > recommend that we go with option 3. Having sub-groups at top level will
> > > > allow us to,
> > > >
> > > > - Provides good visibility on all reviews, tasks and other items within
> > > > the groups/modules we define
> > > > - Provides improvements to discoverability of projects
> > > > - Makes it possible for groups of projects to establish a group level
> > > > task board should it fit their needs (for tracking a release for
> > > > instance)
> > > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > > > in option 2 is duplicative considering the Gitlab instance is under
> > > > kde.org.
> > > > - The discoverability of projects is maximised, as there is no need to
> > > > open the top level ‘KDE’ group before going into the subgroup.
> > > >
> > > > I've worked on draft "move" of the current set of the repositories in
> > > > their respective subgroups at the repo-metadata project's branch [1].
> > > > You can browse the directory structure to get idea of how final
> > > > structure on Gitlab would look like.
> > > >
> > > > If we don't have any objections we would like to implement this next
> > > > week and move projects to https://invent.kde.org.
> > > >
> > > > Thanks!
> > > > Bhushan for sysadmin team
> > > >
> > > > [1] 
> > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> > >
> > > Does this mean that to clone it we'll have to go "git clone
> > > kde:games/knetwalk" or something along the lines?
> > >
> > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > it's already uncomfortable for me to remember the URL for some of the
> > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > problem and I personally don't see the advantage.
> > >
> > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > krita graphics or its own thing?
> > >
> > > I really prefer when I don't have to guess this kind of things when
> > > fetching a repository.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.
> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.

Maybe the middle ground would be to have applications and standalone libraries 
stored flat, and things that go together in a group, the same we tried to 
achieve on api.kde.org by defining products (either a repo or a group of 
repos). 

I guess that you would have
PIM/
Frameworks/

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  wrote:
>
> Hi,
>
> Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > >
> > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > replies]
> > >
> > > Hello Community members,
> > >
> > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > the recommended structuring for the repositories on Gitlab.
> > >
> > > We had multiple options,
> > >
> > > - Flat structure: In this option we would have everything under one
> > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > - Subgroups under top-level group: In this option we would have a groups
> > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > - Groups at top level: In this option we would establish a series of
> > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > >
>
> Thank you for having options and talking to us before implementing it.
>
> > > We have discussed this with small but representative group of
> > > contributors or maintainers, and based on their suggestions, we
> > > recommend that we go with option 3. Having sub-groups at top level will
> > > allow us to,
> > >
> > > - Provides good visibility on all reviews, tasks and other items within
> > > the groups/modules we define
> > > - Provides improvements to discoverability of projects
> > > - Makes it possible for groups of projects to establish a group level
> > > task board should it fit their needs (for tracking a release for
> > > instance)
> > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > > in option 2 is duplicative considering the Gitlab instance is under
> > > kde.org.
> > > - The discoverability of projects is maximised, as there is no need to
> > > open the top level ‘KDE’ group before going into the subgroup.
> > >
> > > I've worked on draft "move" of the current set of the repositories in
> > > their respective subgroups at the repo-metadata project's branch [1].
> > > You can browse the directory structure to get idea of how final
> > > structure on Gitlab would look like.
> > >
> > > If we don't have any objections we would like to implement this next
> > > week and move projects to https://invent.kde.org.
> > >
> > > Thanks!
> > > Bhushan for sysadmin team
> > >
> > > [1] 
> > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
> >
> > I really prefer when I don't have to guess this kind of things when
> > fetching a repository.
> >
>
> I 100% agree with Aleix and I think it would also be detrimental for 
> discoverability, exactly for the examples Aleix just gave.
>
> We came back from this subgroups ideas some times ago : wiki pages were hard 
> to find because hidden under layers of groups. The same was true for api 
> documentations. Now everything is flat and I think it's easier to find.
>
> Another bad message could also be sent by this: instead of exposing Konsole 
> or Ark as two applications under the KDE umbrella, it would look like Utils 
> for KDE, bringing back the KDE Desktop idea (where every application is 
> already store in a submenu).
>
> As someone wrote later, if I'm looking for a given application, there is 
> always the search function...

That requires that you know it exists. We have 1,043 mainline
repositories at the moment, which translates to 53 pages of projects
under a flat structure system.
Reality is nobody is going to page through that looking for something.

Please also see my point regarding listing merge requests at the group
level - you can see an example of what a flat structure ends up
looking like at https://gitlab.gnome.org/GNOME

For those projects that span multiple repositories, you have just
denied them any chance or ability to see a listing of everything
related to their wider project.

>
> Best regards,
> Olivier
> > Aleix
>
>

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration

[Aleix Pol]

On Mon, Apr 27, 2020 at 12:55 PM Ben Cooksley  wrote:
>
> On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol  wrote:
> >
> > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > >
> > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > replies]
> > >
> > > Hello Community members,
> > >
> > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > the recommended structuring for the repositories on Gitlab.
> > >
> > > We had multiple options,
> > >
> > > - Flat structure: In this option we would have everything under one
> > >   single namespace/group: https://invent.kde.org/kde/knetwalk
> > > - Subgroups under top-level group: In this option we would have a groups
> > >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > - Groups at top level: In this option we would establish a series of
> > >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > >
> > > We have discussed this with small but representative group of
> > > contributors or maintainers, and based on their suggestions, we
> > > recommend that we go with option 3. Having sub-groups at top level will
> > > allow us to,
> > >
> > > - Provides good visibility on all reviews, tasks and other items within
> > >   the groups/modules we define
> > > - Provides improvements to discoverability of projects
> > > - Makes it possible for groups of projects to establish a group level
> > >   task board should it fit their needs (for tracking a release for
> > >   instance)
> > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > >   in option 2 is duplicative considering the Gitlab instance is under
> > >   kde.org.
> > > - The discoverability of projects is maximised, as there is no need to
> > >   open the top level ‘KDE’ group before going into the subgroup.
> > >
> > > I've worked on draft "move" of the current set of the repositories in
> > > their respective subgroups at the repo-metadata project's branch [1].
> > > You can browse the directory structure to get idea of how final
> > > structure on Gitlab would look like.
> > >
> > > If we don't have any objections we would like to implement this next
> > > week and move projects to https://invent.kde.org.
> > >
> > > Thanks!
> > > Bhushan for sysadmin team
> > >
> > > [1] 
> > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
>
> Yes.
>
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
>
> So you'd rather that we have no way to easily see a list of just
> Plasma / Frameworks / PIM / etc reviews?
> (See https://invent.kde.org/groups/kde/-/merge_requests for an example
> of the problem)
>
> Not to mention the fact that there will be several hundred
> repositories all in one group, so they will be completely
> undiscoverable to anyone outside of our community.
>
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
> >
> > I really prefer when I don't have to guess this kind of things when
> > fetching a repository.
>
> There is always the search on Gitlab, and you can keep a checkout of
> sysadmin/repo-metadata for grepping on.

I don't know, I've always felt that the nesting we have nowadays
stemmed from svn's tree structure more than convenience.

I don't have the feeling I'd use that feature and I'm happy to
convinced otherwise.

While discoverability would be an incentive, I don't know if it will
make a difference since it would be especially useful to see how
repositories relate one to another, but it's something we generally
split explicitly through frameworks so I don't see that will help
much, other than for the very big suites (kdepim, plasma, etc).

I know you don't like it when I do this, but:
https://gitlab.gnome.org/explore/groups < gnome kept all the programs
under the same group
https://gitlab.freedesktop.org/explore/groups < didn't, but they have
projects that have very little overlap of contributors

Aleix

Re: Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Hi,

Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> >
> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > replies]
> >
> > Hello Community members,
> >
> > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > the recommended structuring for the repositories on Gitlab.
> >
> > We had multiple options,
> >
> > - Flat structure: In this option we would have everything under one
> > single namespace/group: https://invent.kde.org/kde/knetwalk
> > - Subgroups under top-level group: In this option we would have a groups
> > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > - Groups at top level: In this option we would establish a series of
> > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> >

Thank you for having options and talking to us before implementing it.

> > We have discussed this with small but representative group of
> > contributors or maintainers, and based on their suggestions, we
> > recommend that we go with option 3. Having sub-groups at top level will
> > allow us to,
> >
> > - Provides good visibility on all reviews, tasks and other items within
> > the groups/modules we define
> > - Provides improvements to discoverability of projects
> > - Makes it possible for groups of projects to establish a group level
> > task board should it fit their needs (for tracking a release for
> > instance)
> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > in option 2 is duplicative considering the Gitlab instance is under
> > kde.org.
> > - The discoverability of projects is maximised, as there is no need to
> > open the top level ‘KDE’ group before going into the subgroup.
> >
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
> >
> > If we don't have any objections we would like to implement this next
> > week and move projects to https://invent.kde.org.
> >
> > Thanks!
> > Bhushan for sysadmin team
> >
> > [1] 
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?
>
> If that's the case I'd much prefer if we didn't do this, at the moment
> it's already uncomfortable for me to remember the URL for some of the
> repos (e.g. is it sysadmin/ or not?), this will only increase the
> problem and I personally don't see the advantage.
>
> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?
>
> I really prefer when I don't have to guess this kind of things when
> fetching a repository.
>

I 100% agree with Aleix and I think it would also be detrimental for 
discoverability, exactly for the examples Aleix just gave.

We came back from this subgroups ideas some times ago : wiki pages were hard to 
find because hidden under layers of groups. The same was true for api 
documentations. Now everything is flat and I think it's easier to find.

Another bad message could also be sent by this: instead of exposing Konsole or 
Ark as two applications under the KDE umbrella, it would look like Utils for 
KDE, bringing back the KDE Desktop idea (where every application is already 
store in a submenu).

As someone wrote later, if I'm looking for a given application, there is always 
the search function...
  
Best regards,
Olivier
> Aleix

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Mon, Apr 27, 2020 at 10:50 PM Piyush Aggarwal
 wrote:
>
>
>
> On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol,  wrote:
>>
>> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
>> >
>> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
>> > replies]
>> >
>> > Hello Community members,
>> >
>> > In view of upcoming Gitlab migration, we sysadmin team wants to share
>> > the recommended structuring for the repositories on Gitlab.
>> >
>> > We had multiple options,
>> >
>> > - Flat structure: In this option we would have everything under one
>> >   single namespace/group: https://invent.kde.org/kde/knetwalk
>> > - Subgroups under top-level group: In this option we would have a groups
>> >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
>> > - Groups at top level: In this option we would establish a series of
>> >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
>> >
>> > We have discussed this with small but representative group of
>> > contributors or maintainers, and based on their suggestions, we
>> > recommend that we go with option 3. Having sub-groups at top level will
>> > allow us to,
>> >
>> > - Provides good visibility on all reviews, tasks and other items within
>> >   the groups/modules we define
>> > - Provides improvements to discoverability of projects
>> > - Makes it possible for groups of projects to establish a group level
>> >   task board should it fit their needs (for tracking a release for
>> >   instance)
>> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>> >   in option 2 is duplicative considering the Gitlab instance is under
>> >   kde.org.
>> > - The discoverability of projects is maximised, as there is no need to
>> >   open the top level ‘KDE’ group before going into the subgroup.
>> >
>> > I've worked on draft "move" of the current set of the repositories in
>> > their respective subgroups at the repo-metadata project's branch [1].
>> > You can browse the directory structure to get idea of how final
>> > structure on Gitlab would look like.
>> >
>> > If we don't have any objections we would like to implement this next
>> > week and move projects to https://invent.kde.org.
>> >
>> > Thanks!
>> > Bhushan for sysadmin team
>> >
>> > [1] 
>> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>>
>> Does this mean that to clone it we'll have to go "git clone
>> kde:games/knetwalk" or something along the lines?
>>
>> If that's the case I'd much prefer if we didn't do this, at the moment
>> it's already uncomfortable for me to remember the URL for some of the
>> repos (e.g. is it sysadmin/ or not?), this will only increase the
>> problem and I personally don't see the advantage.
>>
>> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
>> krita graphics or its own thing?
>>
>> I really prefer when I don't have to guess this kind of things when
>> fetching a repository.
>>
>> Aleix
>
>
> This is technical so I would love to hear Sysadmin team's thoughts on this: 
> Probably there can be a redirect system that lets us do git clone 
> kde:knotifications and manages to redirect it to 
> kde/frameworks/tier3/knotifications.git
> So we can clone and tinker with stuff as we normally do while the sysadmin 
> team goes with the recommended system of setting up the repos.
> I think this should be possible because Invent already redirects my URLs 
> which don't end with .git to .git ones. I might be wrong about my assumption 
> that both things can work similarly.

That would require modifications to Gitlab, which may not even be
technically possible.
It is likely a rewrite script will be provided to smooth the transition.

Please note that knotifications would go to
https://invent.kde.org/frameworks/knotifications under this proposal,
not the longer path you've referred to above.

>
> Best
> Piyush Aggarwal

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol  wrote:
>
> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> >
> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > replies]
> >
> > Hello Community members,
> >
> > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > the recommended structuring for the repositories on Gitlab.
> >
> > We had multiple options,
> >
> > - Flat structure: In this option we would have everything under one
> >   single namespace/group: https://invent.kde.org/kde/knetwalk
> > - Subgroups under top-level group: In this option we would have a groups
> >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > - Groups at top level: In this option we would establish a series of
> >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> >
> > We have discussed this with small but representative group of
> > contributors or maintainers, and based on their suggestions, we
> > recommend that we go with option 3. Having sub-groups at top level will
> > allow us to,
> >
> > - Provides good visibility on all reviews, tasks and other items within
> >   the groups/modules we define
> > - Provides improvements to discoverability of projects
> > - Makes it possible for groups of projects to establish a group level
> >   task board should it fit their needs (for tracking a release for
> >   instance)
> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> >   in option 2 is duplicative considering the Gitlab instance is under
> >   kde.org.
> > - The discoverability of projects is maximised, as there is no need to
> >   open the top level ‘KDE’ group before going into the subgroup.
> >
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
> >
> > If we don't have any objections we would like to implement this next
> > week and move projects to https://invent.kde.org.
> >
> > Thanks!
> > Bhushan for sysadmin team
> >
> > [1] 
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?

Yes.

>
> If that's the case I'd much prefer if we didn't do this, at the moment
> it's already uncomfortable for me to remember the URL for some of the
> repos (e.g. is it sysadmin/ or not?), this will only increase the
> problem and I personally don't see the advantage.

So you'd rather that we have no way to easily see a list of just
Plasma / Frameworks / PIM / etc reviews?
(See https://invent.kde.org/groups/kde/-/merge_requests for an example
of the problem)

Not to mention the fact that there will be several hundred
repositories all in one group, so they will be completely
undiscoverable to anyone outside of our community.

>
> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?
>
> I really prefer when I don't have to guess this kind of things when
> fetching a repository.

There is always the search on Gitlab, and you can keep a checkout of
sysadmin/repo-metadata for grepping on.

>
> Aleix

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration

[Piyush Aggarwal]

On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol,  wrote:

> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> >
> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > replies]
> >
> > Hello Community members,
> >
> > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > the recommended structuring for the repositories on Gitlab.
> >
> > We had multiple options,
> >
> > - Flat structure: In this option we would have everything under one
> >   single namespace/group: https://invent.kde.org/kde/knetwalk
> > - Subgroups under top-level group: In this option we would have a groups
> >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > - Groups at top level: In this option we would establish a series of
> >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> >
> > We have discussed this with small but representative group of
> > contributors or maintainers, and based on their suggestions, we
> > recommend that we go with option 3. Having sub-groups at top level will
> > allow us to,
> >
> > - Provides good visibility on all reviews, tasks and other items within
> >   the groups/modules we define
> > - Provides improvements to discoverability of projects
> > - Makes it possible for groups of projects to establish a group level
> >   task board should it fit their needs (for tracking a release for
> >   instance)
> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> >   in option 2 is duplicative considering the Gitlab instance is under
> >   kde.org.
> > - The discoverability of projects is maximised, as there is no need to
> >   open the top level ‘KDE’ group before going into the subgroup.
> >
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
> >
> > If we don't have any objections we would like to implement this next
> > week and move projects to https://invent.kde.org.
> >
> > Thanks!
> > Bhushan for sysadmin team
> >
> > [1]
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?
>
> If that's the case I'd much prefer if we didn't do this, at the moment
> it's already uncomfortable for me to remember the URL for some of the
> repos (e.g. is it sysadmin/ or not?), this will only increase the
> problem and I personally don't see the advantage.
>
> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?
>
> I really prefer when I don't have to guess this kind of things when
> fetching a repository.
>
> Aleix
>

This is technical so I would love to hear Sysadmin team's thoughts on this:
Probably there can be a redirect system that lets us do git clone
kde:knotifications and manages to redirect it to
kde/frameworks/tier3/knotifications.git
So we can clone and tinker with stuff as we normally do while the sysadmin
team goes with the recommended system of setting up the repos.
I think this should be possible because Invent already redirects my URLs
which don't end with .git to .git ones. I might be wrong about my
assumption that both things can work similarly.

Best
Piyush Aggarwal

>

Re: Information regarding upcoming Gitlab Migration

[Aleix Pol]

On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> Hello Community members,
>
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
>
> We had multiple options,
>
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
>
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
>
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
>
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
>
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.
>
> Thanks!
> Bhushan for sysadmin team
>
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?

I really prefer when I don't have to guess this kind of things when
fetching a repository.

Aleix

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Mon, Apr 27, 2020 at 7:26 PM Ilya Bizyaev  wrote:
>
> Hello Bhushan!
>
> Thank you for you work on the Gitlab migration!
>
> The lists look good! Here are some ideas that I have, in case you think they 
> can be considered before we transition:
> • The "applications" category is somewhat misleading to me: it does not 
> include all KDE applications, and not all repositories in that category are 
> applications either. Looking through the list of projects in there, I think 
> they can be safely distributed across other categories. Most complicated 
> there are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow 
> terminal emulators, file managers and text editors feel like they belong to 
> the same category, but I don't know how to call it; maybe "files"?

We are aware that the name is not ideal yes, and alternative names
would definitely be welcome for this group of projects.

Alternatively, they could be transferred into other categories (as it
looks like most of them would fit within 'utilities' even if they are
rather essential ones)

> • Tentative, but I think a category called "science" might make sense 
> creating. Since KDE regularly attempts to promote usage of our software in 
> scientific institutions, that wouldn't hurt either. E.g. Mark (an app for 
> data science) doesn't really belong in "education", and I think is also true 
> for labplot and rkward.
> • I see a category named "others". Looking at its contents, maybe it can be 
> renamed to "community"?

Most of these will in the long run be archived, so this category may
not end up being included in the final structure.

>
> Looking forward to the move!
>
> Cheers,
> Ilya.

Thanks,
Ben

>
>
>  Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah  
> написал(а) 
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> Hello Community members,
>
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
>
> We had multiple options,
>
> - Flat structure: In this option we would have everything under one
> single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
> under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
> groups at the top level, e.g. https://invent.kde.org/games/knetwalk
>
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
>
> - Provides good visibility on all reviews, tasks and other items within
> the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
> task board should it fit their needs (for tracking a release for
> instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> in option 2 is duplicative considering the Gitlab instance is under
> kde.org.
> - The discoverability of projects is maximised, as there is no need to
> open the top level ‘KDE’ group before going into the subgroup.
>
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
>
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.
>
> Thanks!
> Bhushan for sysadmin team
>
> [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
>
>
>

Re: Information regarding upcoming Gitlab Migration

[Ilya Bizyaev]

Hello Bhushan!



Thank you for you work on the Gitlab migration!



The lists look good! Here are some ideas that I have, in case you think they 
can be considered before we transition:

• The "applications" category is somewhat misleading to me: it does not include 
all KDE applications, and not all repositories in that category are 
applications either. Looking through the list of projects in there, I think 
they can be safely distributed across other categories. Most complicated there 
are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow terminal 
emulators, file managers and text editors feel like they belong to the same 
category, but I don't know how to call it; maybe "files"?

• Tentative, but I think a category called "science" might make sense creating. 
Since KDE regularly attempts to promote usage of our software in scientific 
institutions, that wouldn't hurt either. E.g. Mark (an app for data science) 
doesn't really belong in "education", and I think is also true for labplot and 
rkward.

• I see a category named "others". Looking at its contents, maybe it can be 
renamed to "community"?



Looking forward to the move!



Cheers,

Ilya.





 Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah  
написал(а) 



[Please keep mailto:sysad...@kde.org list or mailto:bs...@kde.org in the CC for 
replies] 
 
Hello Community members, 
 
In view of upcoming Gitlab migration, we sysadmin team wants to share 
the recommended structuring for the repositories on Gitlab. 
 
We had multiple options, 
 
- Flat structure: In this option we would have everything under one 
 single namespace/group: https://invent.kde.org/kde/knetwalk 
- Subgroups under top-level group: In this option we would have a groups 
 under KDE namespace: https://invent.kde.org/kde/games/knetwalk 
- Groups at top level: In this option we would establish a series of 
 groups at the top level, e.g. https://invent.kde.org/games/knetwalk 
 
We have discussed this with small but representative group of 
contributors or maintainers, and based on their suggestions, we 
recommend that we go with option 3. Having sub-groups at top level will 
allow us to, 
 
- Provides good visibility on all reviews, tasks and other items within 
 the groups/modules we define 
- Provides improvements to discoverability of projects 
- Makes it possible for groups of projects to establish a group level 
 task board should it fit their needs (for tracking a release for 
 instance) 
- Makes the most semantic sense, as the ‘KDE’ top level group suggested 
 in option 2 is duplicative considering the Gitlab instance is under 
 kde.org. 
- The discoverability of projects is maximised, as there is no need to 
 open the top level ‘KDE’ group before going into the subgroup. 
 
I've worked on draft "move" of the current set of the repositories in 
their respective subgroups at the repo-metadata project's branch [1]. 
You can browse the directory structure to get idea of how final 
structure on Gitlab would look like. 
 
If we don't have any objections we would like to implement this next 
week and move projects to https://invent.kde.org. 
 
Thanks! 
Bhushan for sysadmin team 
 
[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

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Mon, Apr 27, 2020 at 6:33 PM Rolf Eike Beer  
wrote:
>
> Bhushan Shah wrote:
>
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
>
> No objection, just a request for clarification: it looks like everything
> in extragear or playground was merged into there, right?

That is correct - the Extragear/Playground/"KDE" modules aren't
represented in this.

>
> Eike

Cheers,
Ben