Re: Information regarding upcoming Gitlab Migration
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Fwd: Quanta
> Your quanta was singularly the best html editor > I had found. It now does not work without a > dcopserver. Forwarded Message Subject: Re: Quanta Date: Mon, 27 Apr 2020 12:27:36 +0300 From: Andras Mantia To: William Chimiak Hi, First of all thanks for the compliments. Unfortunately I stopped working on Quanta long ago for various reasons. Although I still have some contact with the KDE community and use KDE daily, I don't do much development there. That said, I can't offer you a solution unfortunately. DCOP was part of KDE 3, so it is quite old stuff, not surprised it is not shipped anymore on recent distributions. What I could suggest to is to write a mail at kde-devel@kde.org asking if anyone is interested in porting Quanta away from DCOP at least, as full port would be quite a lot of work. Sorry for not being able to help you now, Andras On Sunday, April 26, 2020 4:09:30 AM EEST William Chimiak wrote: > Your quanta was singularly the best html editor > I had found. It now does not work without a > dcopserver. I wish there was a way to use it > without that. It helped me make simple, > great-looking web pages. These days, I am > not really keen on opening up my machine > to the web, except when I need to. I only > need this as a user. If I must start > dcopserver to use quanta, what is the safest > way to do that from an information security > standpoint? > > Thanks in advance.
Re: Information regarding upcoming Gitlab Migration
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: Information regarding upcoming Gitlab Migration
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
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
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
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
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 h
Re: Information regarding upcoming Gitlab Migration
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
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, yo
Re: Information regarding upcoming Gitlab Migration
Hi Nate, On Mon, Apr 27, 2020 at 07:45:23AM -0600, Nate Graham wrote: > 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. I've agreed in previous threads that sometime our grouping is not perfect, but this is something we can improve instead of throwing idea of grouping out altogether. > 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 No goal is not just that you get nice list of all open merge requests or issues. Main goal is we want to offer user or potential contributors a list of closely related projects instead of list of all 1100+ projects we have. That would mean, If user wants to see all frameworks, or graphics applications, or multimedia applications, they can. The workflow, with labels you mention is trying to achieve a totally different goal then what we are trying to solve here. Labels/Tags are for sorting issues, and/or merge requests. They can't be reliable solution for the sorting of the multiple repositories. On technical side, Gitlab does not offer labels for projects, but setting called topic. You can see that in screenshot[1] linked. Besides, from home page there's no way to filter something for e.g "Graphics". nore project listing shows the tags alongside of the project names, also making use of this tags means that if user clicks this tags, what they are offered is *all* the repositories including forks of the repositories, which means when you search for graphics [2], you get many duplicative results and this is really not something discoverable. > 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). As explained above, while grouping repositories is trying to solve the merge requests/issue organization, it is not sole purpose of the suggested grouping, discoverability and reachability is the main issue we are trying to solve here. [1] https://i.imgur.com/h1L1A5H.png [2] https://i.imgur.com/ajOszEL.png -- 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
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: Information regarding upcoming Gitlab Migration
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
