D29229: [KPlotting] Port foreach (deprecated) to range for

[Ahmad Samir]

ahmadsamir created this revision.
ahmadsamir added reviewers: Frameworks, dfaure, apol, meven.
Herald added a project: Frameworks.
ahmadsamir requested review of this revision.

TEST PLAN
  make && ctest

REPOSITORY
  R277 KPlotting

BRANCH
  l-foreach (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29229

AFFECTED FILES
  src/kplotobject.cpp
  src/kplotwidget.cpp

To: ahmadsamir, #frameworks, dfaure, apol, meven
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Re: Splitting KWayland

[David Edmundson]

On Mon, Apr 27, 2020 at 2:12 PM David Edmundson 
wrote:

>
>
> On Mon, Apr 27, 2020 at 1:58 PM Aleix Pol  wrote:
>
>> Hi,
>> As discussed in the meeting last week, I've been looking into the split.
>>
>> Here's what I was thinking of, please tell me if there's something
>> massively important I'm missing.
>>
>> The idea would be to start working on it after kwayland and other kf5
>> have been tagged next week (?).
>>
>> Something I was wondering too is that I guess the new repos should end
>> up in invent? Although neither plasma or kf5 are there.
>> So maybe not?
>>
>
> Given the recent gitlab status update from bshah, that'll be happening
> soon.
>
>>
>> There's a couple of questions below as well, thoughts would be welcome
>>
>> Aleix
>>
>> git clone kde:kwayland
>> mv kwayland plasma-wayland-protocols
>> cd plasma-wayland-protocols
>> git rm -r autotests/ docs/ tests/ src/
>> # fix build
>> # close https://phabricator.kde.org/T13024
>
>
> And changing it so we install the KDE specific protocol files
>
>
>> git clone kde:kwayland
>> mv kwayland/ kwayland-server
>>
>
> git rm -r src/client/
>> # namespace KWayland::Server -> namespace KWaylandServer
>> # fix build
>> # remove server tests?
>>
>
> I don't think we want to remove client or server tests on this one. As the
> client tests covered the server side too
> Even if it does mean some short-term duplication.
>
>
>> # see to move things to KWin?
>>
>
> I don't know which things you were referring to, but I'd suggest we keep
> things simple.
>
>>
>> # close https://phabricator.kde.org/T13025
>
>
>
>
>> git clone kde:kwayland
>>
>
> git rm src/client/protocols and use the installed ones from the first repo
>
>
>> # deprecate all KWayland::Server
>
>
> We need a big README in the src/server. IMO it's not worth the hassle of
> changing the header files.
>
> # remove server tests?
>>
> Yeah, can do.
>
>
>
>
>
>

Re: Splitting KWayland

[David Edmundson]

On Mon, Apr 27, 2020 at 1:58 PM Aleix Pol  wrote:

> Hi,
> As discussed in the meeting last week, I've been looking into the split.
>
> Here's what I was thinking of, please tell me if there's something
> massively important I'm missing.
>
> The idea would be to start working on it after kwayland and other kf5
> have been tagged next week (?).
>
> Something I was wondering too is that I guess the new repos should end
> up in invent? Although neither plasma or kf5 are there.
> So maybe not?
>

Given the recent gitlab status update from bshah, that'll be happening
soon.

>
> There's a couple of questions below as well, thoughts would be welcome
>
> Aleix
>
> git clone kde:kwayland
> mv kwayland plasma-wayland-protocols
> cd plasma-wayland-protocols
> git rm -r autotests/ docs/ tests/ src/
> # fix build
> # close https://phabricator.kde.org/T13024


And changing it so we install the KDE specific protocol files


> git clone kde:kwayland
> mv kwayland/ kwayland-server
>

git rm -r src/client/
> # namespace KWayland::Server -> namespace KWaylandServer
> # fix build
> # remove server tests?
>

I don't think we want to remove client or server tests on this one. As the
client tests covered the server side too
Even if it does mean some short-term duplication.


> # see to move things to KWin?
>

I don't know which things you were referring to, but I'd suggest we keep
things simple.

>
> # close https://phabricator.kde.org/T13025




> git clone kde:kwayland
>

git rm src/client/protocols and use the installed ones from the first repo


> # deprecate all KWayland::Server


We need a big README in the src/server. IMO it's not worth the hassle of
changing the header files.

# remove server tests?
>
Yeah, can do.

D28882: Create protocol to manage video feeds

[Méven Car]

meven added inline comments.

INLINE COMMENTS

> screencasting.cpp:141
> +}
> +void zkde_screencast_unstable_v1_removeSource(uint32_t sourceId) 
> override {
> +auto it = std::find_if(m_sources.begin(), m_sources.end(), 
> [sourceId] (const ScreencastingSource ) {

Missing blank line

> screencasting.cpp:156
> +
> +
> +

Two blank lines too mang

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D28882

To: apol, #kwin, jgrulich, davidedmundson
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns

D29228: [KProcessRunner] Use only executable name for scope

[Kai Uwe Broulik]

broulik created this revision.
broulik added reviewers: Frameworks, Plasma.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
broulik requested review of this revision.

REVISION SUMMARY
  Slashes aren't allowed in scope names, so when a full executable path is 
launched, e.g. ´/usr/bin/foo` it would fail to be scoped.
  It's kinda wrong, too, but better than not scoping it at all.

TEST PLAN
  In D29226  I now have my session restored 
apps in scopes, though they're naturally not the same ones as when I have a 
desktop entry associated with the launch job

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29228

AFFECTED FILES
  src/gui/kprocessrunner.cpp

To: broulik, #frameworks, #plasma
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Splitting KWayland

[Aleix Pol]

Hi,
As discussed in the meeting last week, I've been looking into the split.

Here's what I was thinking of, please tell me if there's something
massively important I'm missing.

The idea would be to start working on it after kwayland and other kf5
have been tagged next week (?).

Something I was wondering too is that I guess the new repos should end
up in invent? Although neither plasma or kf5 are there.
So maybe not?

There's a couple of questions below as well, thoughts would be welcome

Aleix

git clone kde:kwayland
mv kwayland plasma-wayland-protocols
cd plasma-wayland-protocols
git rm -r autotests/ docs/ tests/ src/
# fix build
# close https://phabricator.kde.org/T13024

git clone kde:kwayland
mv kwayland/ kwayland-server
git rm -r src/client/
# namespace KWayland::Server -> namespace KWaylandServer
# fix build
# remove server tests?
# see to move things to KWin?
# close https://phabricator.kde.org/T13025

git clone kde:kwayland
# deprecate all KWayland::Server
# remove server tests?

Re: KF 5 & C++14?

[Friedrich W. H. Kossebau]

Am Montag, 27. April 2020, 00:45:41 CEST schrieb David Faure:
> On Sunday, April 26, 2020 5:30:37 PM CEST Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > I just saw that at least kimageformats, knewstuff & kquickcharts all set
> > this: set(CMAKE_CXX_STANDARD 14)
> > 
> > set(CMAKE_CXX_STANDARD_REQUIRED ON)
> > 
> > Which ignores a bit that so far C++11 has been the minimum standard
> > officially supported in/by KDE Frameworks (by mainly following what Qt 5
> > supports).
> > 
> > Compare also the current text of the policy
> > "Frameworks compiler requirements and C++11":
> > --- 8< ---
> > The following minimal compiler versions are supported by KDE Frameworks:
> > * GCC 4.8
> > * Clang 3.3
> > * VS2013 (MSVC12)
> > 
> > This means all of the C++11 standards can be used.
> > --- 8< ---
> > * https://community.kde.org/Frameworks/
> > Policies#Frameworks_compiler_requirements_and_C.2B.2B11
> > 
> > What to make of this? Might it be the time to raise the bars a bit, and
> > how
> > much? Surely the lower limit is what the oldest Qt version currently
> > supported by KDE Frameworks claims to support:
> > https://doc.qt.io/qt-5.12/supported-platforms.html
> > 
> > Should we go above this?
> > Or should kimageformats, knewstuff & kquickcharts be fixed to use C++11
> > only again?
> > 
> > No own opinion, so far only stumbled over what seems a policy breakage.
> 
> The goal was to align with the requirements of the Qt version we require.
> 
> But it's hard to know if anyone is actually using gcc 4.8 to build the
> current version of KF5. One way to find out is to... do nothing. Leave the
> above as is and see if anyone actually complains that it doesn't match our
> promise.

For reference, the CMAKE_CXX_STANDARD 14 is present in those modules...
KQuickCharts:  since KF 5.65 (== addition of module)
KNewStuff: since KF 5.69
KImageFormats: since KF 5.70
So relatively new, meaning the field observation phase only just began :)

> This isn't however a green light for doing this everywhere, not until we
> wait multiple months for feedback. Otherwise the porting effort (down to
> C++11) will be huge.

One personal motivation to ask was the hope that we could go C++14 across all 
KF modules now. Not needing to support C++11 anymore, but relying on C++14 
deprecation tagging features would simplify ECMGenerateExportHeader code and, 
what triggered me here, make it simple to extend version-based deprecation 
tagging also for enumerators.
Guess I am out of luck then for now, or have to post-pone the feature :)

Cheers
Friedrich

D28882: Create protocol to manage video feeds

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> screencast.xml:46
> +
> +
> +

add type = "destructor"

so that clients calling this release the resource

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D28882

To: apol, #kwin, jgrulich, davidedmundson
Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

Re: Having $(framework)_global.h headers (was: Re: building KF5 projects against a different Qt5 version [...])

[Friedrich W. H. Kossebau]

Am Sonntag, 26. April 2020, 16:12:31 CEST schrieb Friedrich W. H. Kossebau:
> Am Sonntag, 26. April 2020, 15:46:35 CEST schrieb David Faure:
> > On Sunday, April 26, 2020 3:21:34 PM CEST René J.V. Bertin wrote:
> > > Talking about version test hacks (or not-so-hacks): why is it that
> > > KFOO_VERSION isn't defined systematically when you include any header of
> > > the FOO KF5 framework? With Qt you never have to worry about QT_VERSION
> > > being defined.
> > 
> > Well, everything in Qt ends up including global.h
> > There's no such central header in KF5 frameworks (which are more modular,
> > by definition), so you need to include the framework_version.h header.
> We could perhaps look into extending the export headers into some kind of $
> (framework)_global.h headers, like we are now doing already a bit for all
> the deprecation definitions when using ecm_generate_export_header, where
> all additional stuff is injected via the export headers.
> 
> I also found a bit annoying to have to add all the explicit includes of
> framework_version.h every time one wanted to access KFOO_VERSION.
> 
> So far had only pondered the idea at that time, no yet investigated further
> given state of own TODO list :) Also low motivation given that there would
> need to be a backward-compatible setup, and usually one uses that very
> version header to be compatible to old versions, so there was no immediate
> gain. But long time (at least KF6) I would also prefer to see the version
> macros available by default.

And I meanwhile noticed that the actual version number of a library is already 
present in the export headers generated with ECMGenerateExportHeader, due to 
being a possible default number for all the version-dependent calculations for 
what to show warnings or which API to hide. Not accessible as macro though, so 
do not have hopes to "abuse" this :)

Given this kept following me into my shower thoughts this morning, guess I 
will soonish be working on some ECMGenerateGlobalHeader then, or at least 
explore more for now in some non-ECM projects the feasibility of semi-
generation of such global header carrying all the stuff interesting with all 
the (public) API of a library. Ping me again in autumn about this.

Cheers
Friedrich

D29223: Update Taiwanese holidays

[Christophe Giboudeaux]

cgiboudeaux added a comment.


  I suppose you rename the file for a good reason. Are there different 
"official" languages for Taiwan?

REPOSITORY
  R175 KHolidays

REVISION DETAIL
  https://phabricator.kde.org/D29223

To: nhiga, winterz, cgiboudeaux, shrapnel
Cc: #kde_pim, kde-frameworks-devel, shrapnel, LeGast00n, cblack, fbampaloukas, 
dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

D29223: Update Taiwanese holidays

[Christophe Giboudeaux]

cgiboudeaux added a reviewer: shrapnel.

REPOSITORY
  R175 KHolidays

REVISION DETAIL
  https://phabricator.kde.org/D29223

To: nhiga, winterz, cgiboudeaux, shrapnel
Cc: #kde_pim, kde-frameworks-devel, shrapnel, LeGast00n, cblack, fbampaloukas, 
dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

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

[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

D29223: Update Taiwanese holidays

[N. Higa]

nhiga added a comment.


  Notes:
  
  1. Holidays for indigenous peoples have not been included. Some of them seem 
to have a fixed date, but for other festivals we know the range but not the 
exact dates. For example, it is known that 豐年祭(收穫祭) is celebrated between July 
1 and September 30 (source 
),
 but the actual date (which is also a day off for the respective ethnic group) 
is picked by the Amis people. This calendar 

 does not give us any hint on the exact date of 豐年祭.
  2. 勞動節 (Labor Day) is a day off for many people, but at the same time civil 
servants, teachers, etc. do not have a day off, so I did not mark it as 
"public". Similarly, "軍人節" is a day off for military members only, and others 
do not have a day off.
  3. Some holidays such as Children's Day are referred to as festivals (節日) and 
not as commemorative days (紀念日), but for simplicity, I am marking them as 
"commemorative".

REPOSITORY
  R175 KHolidays

REVISION DETAIL
  https://phabricator.kde.org/D29223

To: nhiga, winterz, cgiboudeaux
Cc: #kde_pim, kde-frameworks-devel, shrapnel, LeGast00n, cblack, fbampaloukas, 
dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

Re: changing icon sizes no longer emits signal

[Kai Uwe Broulik]

(That's why confirmation prompts are pointless, one gets so used to just 
acknowledge them all that that I sent this mail mid-sentece :)


...so perhaps we should just change it to always emit the dbus signal 
manually when something changed, rather than it being nested inside 
exportToKDE4().


So, basically like David's patch, except maybe just with the explicit 
DBus call, so we can get rid of the emitChange call, which I think might 
be kdelibs4support material?


Cheers
Kai Uwe

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: changing icon sizes no longer emits signal

[Kai Uwe Broulik]

Hi,


A patch like the one attached seems to help, but someone who knows the KCM
better (or has time to dig) should make this conditional on the user actually
changing icon sizes, and only emit for the groups that have changed.


Patch makes sense, though I wonder why we do both emitChange and a 
manual DBus call. From what I gather emitChange does the same.


Plasma-Integration also connects to that signal to update icon sizes.

It looks like a flaw in the previous code, where it would always run 
exportToKDE4() when anything was changed, which would then emit the 
signal, which unbeknownst to me, was also still being used :)


In Plasma 5.17 it used to be:
> if (m_selectedThemeDirty || m_iconSizesDirty || m_revertIconEffects) {
> exportToKDE4();
> }

So perha

D29198: filenamesearch:/ define a title for the query

[Méven Car]

meven updated this revision to Diff 81330.
meven marked an inline comment as done.
meven added a comment.


  Rename DolphinSearchBox::getQueryTitle to DolphinSearchBox::queryTitle

REPOSITORY
  R318 Dolphin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29198?vs=81246=81330

BRANCH
  arcpatch-D29198_1

REVISION DETAIL
  https://phabricator.kde.org/D29198

AFFECTED FILES
  src/search/dolphinsearchbox.cpp
  src/search/dolphinsearchbox.h

To: meven, ngraham, elvisangelaccio, #dolphin, #frameworks
Cc: iasensio, kfm-devel, azyx, nikolaik, pberestov, aprcela, fprice, 
fbampaloukas, alexde, Codezela, feverfew, meven, spoorun, navarromorales, 
firef, ngraham, andrebarros, emmanuelp, rdieter, mikesomov

D29197: filenamesearch: Implement stat to display metainfo

[Méven Car]

meven added a reviewer: elvisangelaccio.

REPOSITORY
  R320 KIO Extras

REVISION DETAIL
  https://phabricator.kde.org/D29197

To: meven, #dolphin, #frameworks, ngraham, elvisangelaccio
Cc: kde-frameworks-devel, kfm-devel, azyx, nikolaik, pberestov, iasensio, 
aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, feverfew, 
meven, michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, rdieter, mikesomov

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

D29223: Update Taiwanese holidays

[N. Higa]

nhiga created this revision.
nhiga added reviewers: winterz, cgiboudeaux.
nhiga added projects: KDE PIM, Frameworks.
nhiga requested review of this revision.

REVISION SUMMARY
  This patch improves upon @shrapnel 's work 
 on the accuracy of the Taiwanese holidays 
file:
  
  - Some holidays are determined based on the Lunar Calendar, and their 
specific dates have to be manually specified for each year
  - Official holiday names are now used
  - Try to put a holiday in the correct categories
  
  The following has been excluded:
  
  - Holidays (Festivals) for indigenous peoples (原住民族歲時祭儀)
  - Non-official holidays such as Halloween and Christmas

REPOSITORY
  R175 KHolidays

REVISION DETAIL
  https://phabricator.kde.org/D29223

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_tw_zh
  holidays/plan2/holiday_tw_zh-tw

To: nhiga, winterz, cgiboudeaux
Cc: #kde_pim, kde-frameworks-devel, shrapnel, LeGast00n, cblack, fbampaloukas, 
dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

D29170: Detect executables without +x permission in $PATH to improve error message

[David Faure]

dfaure added a comment.


  In D29170#658058 , @meven wrote:
  
  > Is it not sufficient to fix bug 415567 ? In which case replace in commit 
comment CCBUG by BUG
  
  
  No, that bug has two issues. "Program not found" and "Missing lib" -- which 
is another issue, to be solved in a future commit.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_findExecutable

REVISION DETAIL
  https://phabricator.kde.org/D29170

To: dfaure, ahmadsamir
Cc: meven, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29222: Fix update auto selection

[Dan Leinir Turthra Jensen]

leinir edited the summary of this revision.
leinir added reviewers: Frameworks, Plasma, bugseforuns, ngraham.

REPOSITORY
  R304 KNewStuff

REVISION DETAIL
  https://phabricator.kde.org/D29222

To: leinir, #frameworks, #plasma, bugseforuns, ngraham
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29222: Fix update auto selection

[Dan Leinir Turthra Jensen]

leinir created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
leinir requested review of this revision.

REVISION SUMMARY
  The new autoselection for updating installed entries would firstly
  not be looking at the right amount of download links, and further it
  would not be able to identify the links it needed to, as it did not
  look at the descriptive names (where the filename is often stored),
  which then would not match. These changes ensure that we look at
  the right bits of information when doing this check. End result is
  that updating works.
  
  - Ensure that the cache doesn't forget installing and updating items
  - Analyse more of the download link information, and use correct counts

TEST PLAN
  Find an item in some KNS dialog in need of updating, and click the Update 
button
  
  On the console, when launched using the correct logging categories, will
  tell you about the selection process (and the UI will show that an update
  is in progress, and eventually that it is completed). To do this check with
  the icons kcm, run it like so:
  
QT_LOGGING_RULES="org.kde.knewstuff*=true" kcmshell5 kcm_icons

REPOSITORY
  R304 KNewStuff

BRANCH
  fix-update-autoselection (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29222

AFFECTED FILES
  src/core/cache.cpp
  src/core/engine.cpp

To: leinir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29219: [KFontChooser] Remove NoFixedCheckBox DisplayFlag, redundant

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R236:5d803a237955: [KFontChooser] Remove NoFixedCheckBox 
DisplayFlag, redundant (authored by ahmadsamir).

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29219?vs=81291=81317

REVISION DETAIL
  https://phabricator.kde.org/D29219

AFFECTED FILES
  src/kfontchooser.cpp
  src/kfontchooser.h
  tests/kfontchooserdialogtest.cpp

To: ahmadsamir, #frameworks, dfaure, cfeck, bport
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29221: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType

[Ahmad Samir]

ahmadsamir created this revision.
ahmadsamir added reviewers: Frameworks, dfaure, meven, bruns.
Herald added a project: Frameworks.
ahmadsamir requested review of this revision.

REVISION SUMMARY
  As was discussed in https://phabricator.kde.org/D29138 and on IRC (with
  frinring and vkrause), add a new enumerator to MediumType with value 0
  to indicate no-op. Change one for-loop to use the new enumerator with
  QMap::value(key, defaultValue).

TEST PLAN
  make && ctest

REPOSITORY
  R245 Solid

BRANCH
  l-mediumtypes (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29221

AFFECTED FILES
  src/solid/devices/backends/fakehw/fakecdrom.cpp
  src/solid/devices/frontend/opticaldrive.h

To: ahmadsamir, #frameworks, dfaure, meven, bruns
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

KDE CI: Frameworks » solid » kf5-qt5 FreeBSDQt5.14 - Build # 12 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/solid/job/kf5-qt5%20FreeBSDQt5.14/12/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 09:25:56 +
 Build duration:
1 min 17 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 test(s)Failed: projectroot.autotests.halbasictest

D29138: [Solid] Replace foreach (deprecated) with range/index for

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R245:b9abef40855e: [Solid] Replace foreach (deprecated) with 
range/index for (authored by ahmadsamir).

REPOSITORY
  R245 Solid

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29138?vs=81131=81314

REVISION DETAIL
  https://phabricator.kde.org/D29138

AFFECTED FILES
  src/imports/devices.cpp
  src/solid/devices/backends/fakehw/fakecdrom.cpp
  src/solid/devices/backends/fakehw/fakedevice.cpp
  src/solid/devices/backends/fakehw/fakemanager.cpp
  src/solid/devices/backends/fakehw/fakeopticaldisc.cpp
  src/solid/devices/backends/fakehw/fakeprocessor.cpp
  src/solid/devices/backends/fakehw/fakestorageaccess.cpp
  src/solid/devices/backends/fstab/fstabdevice.cpp
  src/solid/devices/backends/fstab/fstabmanager.cpp

To: ahmadsamir, #frameworks, dfaure, apol, meven
Cc: bruns, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham

D29138: [Solid] Replace foreach (deprecated) with range/index for

[Ahmad Samir]

ahmadsamir added inline comments.

INLINE COMMENTS

> bruns wrote in fakeopticaldisc.cpp:43
> Thats not a cast but a constructor, see QFlags documentation

From opticaldrive.h:
Q_DECLARE_FLAGS(MediumTypes, MediumType)

AFAIU, MediumTypes is the QFlags, MediumType is the enum. So 
Solid::OpticalDrive::MediumType(0) is the enum not the QFlags.

I'll land this and create a separate diff to add an enumerator 
UnknownMediumType to the MediumType enum, then use it in the for loop.

REPOSITORY
  R245 Solid

BRANCH
  l-foreach (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29138

To: ahmadsamir, #frameworks, dfaure, apol, meven
Cc: bruns, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham

D29170: Detect executables without +x permission in $PATH to improve error message

[Méven Car]

meven added a comment.


  Is it not sufficient to fix bug 415567 ? In which case replace in commit 
comment CCBUG by BUG

INLINE COMMENTS

> desktopexecparser.cpp:40
>  #include 
> +#include 
>  

Not needed.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_findExecutable

REVISION DETAIL
  https://phabricator.kde.org/D29170

To: dfaure, ahmadsamir
Cc: meven, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29219: [KFontChooser] Remove NoFixedCheckBox DisplayFlag, redundant

[David Faure]

dfaure accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  l-remove-redundant-displayflag (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29219

To: ahmadsamir, #frameworks, dfaure, cfeck, bport
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D27859: [server] Expose SurfaceRole class

[Vlad Zahorodnii]

zzag abandoned this revision.
zzag added a comment.


  Given our planned kwaylandserver changes, we don't need this patch.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D27859

To: zzag, #kwin
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

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

D29170: Detect executables without +x permission in $PATH to improve error message

[Ahmad Samir]

ahmadsamir accepted this revision.
ahmadsamir added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> kprocessrunner.cpp:65
> +const QStringList searchPaths = 
> QString::fromLocal8Bit(qgetenv("PATH")).split(QDir::listSeparator(), 
> skipEmptyParts);
> +const QDir currentDir = QDir::current();
> +for (const QString  : searchPaths) {

I guess there is no need to use QDir::current() any more.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_findExecutable

REVISION DETAIL
  https://phabricator.kde.org/D29170

To: dfaure, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

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

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