Re: KDE Frameworks 6.2

[dropping kde-announce] Hello folks, Can we get a new release of Kirigami that includes https://invent.kde.org/frameworks/kirigami/-/commit/722dc268ccc8921552c027d67d5b11d1d5307ec9? This fixes a significant issue that snuck into the release which breaks a bunch of dialogs in System Settings,

Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

On 11/5/23 07:42, Kevin Ottens wrote: I was clumsily advocating for this Akademy 2021 or 2022 (can't remember which). This way it's clearer to application authors when they tie themselves to a given workspace or not. Also, isn't Elisa able to work without Baloo? It even seems to do the right

Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

On 11/5/23 07:09, christ...@cullmann.io wrote: On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote: Hi, with plasma-framework, kactivities and kactivities entering the Plasma product bundle, I assume they also will adapt to Plasma versioning. Hi, if we are atm moving stuff, might it make

Re: Planning the final 6 release timeframes

Thanks for organizing this, David. Where and how will the meeting be held? Nate On 8/22/23 09:22, David Edmundson wrote: A time has been chosen on the poll with a clear winner: 4th September 18:00 CEST See you all there David Edmundson

Re: New

On 11/17/22 02:08, David Faure wrote> Done: kconfig v5.100.1 f4dcf631e9f22e25c768c323762672716ddbdd02 8bbb7951d74e8e289f7b0599887ef328b2726fdbdaae18effda2c9d7f18a82da sources/kconfig-5.100.1.tar.xz plasma-framework v5.100.1 0435ec52c76092bc8a8e2703fa0acbbb63484dfe

New

Hello frameworks and release folks, We had a few major regressions in the 5.100 release that have already been fixed; see: - https://invent.kde.org/frameworks/kconfig/-/merge_requests/148 - https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/652 These are significant enough

Re: KF 5.95-rc1 delayed

On 6/9/22 11:18, Nate Graham wrote: Both are merged now. I think that should be everything. ...One more regression was found which is fixed with https://invent.kde.org/frameworks/plasma-framework/-/commit/1fb2198fcee0ec909fed2f1cb6f2d16f27513d57. Can you please add that to the 5.25 tarball

Re: Notice of withdrawal of CI services: KDevelop and KDE Connect

This kind of problem will be generically solved for everyone once we get GitLab's pre-commit CI, which can block merging of MRs until the failures are resolved--so they actually *will* be resolved. How soon can we get that finally rolled out across KDE? Until that happens, this sort of

Re: github pull requests are piling up

On 12/29/20 11:55 AM, Albert Astals Cid wrote: El dijous, 24 de desembre de 2020, a les 11:02:16 CET, Albert Astals Cid va escriure: We're at 52 at this point https://github.com/pulls?q=is%3Aopen+is%3Apr+user%3AKDE Sadly my bot broke and fixing it is not possible for me in the time i can

Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

We are trying to fix the test failure. See https://invent.kde.org/frameworks/breeze-icons/-/commit/8fce580335ef86f19df2238f00270820ac74c9f4#note_115164 for the current status. Or was the regression caused by something else? Nate On 10/6/20 3:59 AM, Ben Cooksley wrote: Hi all, This

Re: KEmoticons, emoticons kcm

On 5/22/20 6:49 PM, Aleix Pol wrote: Hi, I was looking through some Plasma code and I saw that we have some fairly old emoticons KCM using KF5Emoticons. Now while I know why this exists, it feels like it's more of a thing of the past from when people wrote :) instead of . While keeping it

Re: Request for ktexteditor patch release

If we're adding stuff to a 5.70 bugfix point release, https://cgit.kde.org/kio.git/commit/?id=8769b6360d87c1b688eac4d0ce97594351bad13c is another good candidate, which fixes a recent regression (https://bugs.kde.org/show_bug.cgi?id=421213). Nate On 5/15/20 4:42 AM, Friedrich W. H. Kossebau

Re: Adding a patch to 5.70

Thanks everyone! Nate On 5/3/20 11:08 AM, David Faure wrote: On Sunday, May 3, 2020 6:31:44 PM CEST Filip Fila wrote: Dear Frameworks maintainers, Would it be possible to add this (https://phabricator.kde.org/D29352) patch to the 5.70 release? The change concerns not breaking third-party

Re: Information regarding upcoming Gitlab Migration

On 5/1/20 2:09 PM, Ben Cooksley wrote: Unfortunately sharing of projects/repositories across groups does not impact on tasks and reviews. This means that merge requests for Planet (which is currently shared with "KDE") do not show up in the list of merge requests for "KDE". Sharing repositories

Re: Information regarding upcoming Gitlab Migration: clarifications

On 5/1/20 9:02 AM, Johan Ouwerkerk wrote: No, that is not the default. Actually, it is: https://invent.kde.org/kde/kdesrc-build/-/blob/master/kdesrc-build-setup#L389 and download all repos into ~/kde/src without any of the levels of hierarchy. But it is sufficiently common that there

Re: Information regarding upcoming Gitlab Migration

Thanks for the clarifications, Ben. Then I think the original proposal is perfectly reasonable and I fully support it. Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

On 4/30/20 11:17 PM, Ben Cooksley wrote: Not necessarily. Git allows you to override the name that the local folder is called when cloning, so there is no reason why we can't specify something in the metadata to override the local name that the folder gets called in your local checkout

Re: Information regarding upcoming Gitlab Migration: clarifications

On 4/30/20 5:59 PM, Aleix Pol wrote: El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid Am I the only person that just has all the repos on the same folder? I thought it was the common thing to do :? I do too Same here. kdesrc-build's default settings do this, and download all

Re: Information regarding upcoming Gitlab Migration: clarifications

On 4/30/20 11:43 AM, Aleix Pol wrote: IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. I feel like these things make us look distant, it's important that people's skills translate automatically when they want to get started. True, but if you're a new contributor,

Re: Information regarding upcoming Gitlab Migration

If I'm understanding things, we have solutions to most or all of the objections raised so far: - Projects will be allowed to live in--or at least appear in--multiple top-level groups (e.g. plasma-framework could appear in both the Frameworks top-level group and also the Plasma top-level

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

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

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

Re: Update on Status of Gitlab Migration

On 4/13/20 6:59 PM, Ben Cooksley wrote: Why do we need to mimic them? If you Google "KDE Gitlab" then the first hit is invent.kde.org . To flip it around: why do we need to do something different? I don't think it's about mimicking anyone else, but rather using the

Re: Update on Status of Gitlab Migration

On 4/13/20 4:44 AM, Albert Vaca Cintora wrote: Regarding this: is the subdomain going to stay invent.kde.org once we have officially moved? I find it's a bit confusing to use that instead of gitlab.kde.org I agree. gitlab.kde.org would make more sense to me, mirroring phabricator.kde.org.

Re: 2 kirigami fixes for a point release

On 2/18/20 1:37 PM, Albert Astals Cid wrote: I still don't see why this is a problem, as said Plasma depends on a myriad of libraries that are building each with their own release model, most probably with no bugfix releases at all either. The "we don't control the whole stack" argument does

Re: 2 kirigami fixes for a point release

On 2/18/20 2:13 PM, Luca Beltrame wrote: In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto: Neon is already an OS, whether or not you want to admit it. It's installed from an ISO. A hardware vendor (Slimbook) is shipping it on Erm, where did I say that in my reply

Re: 2 kirigami fixes for a point release

On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote: Yes, this has been questioned a few times. Also seeing Plasma LTS used together with a non-LTS Qt is a bit strange. But somehow it seems there has not been enough pain for those using the Plasma LTS to change something. Possibly because

Re: 2 kirigami fixes for a point release

On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote: Yes, this has been questioned a few times. Also seeing Plasma LTS used together with a non-LTS Qt is a bit strange. But somehow it seems there has not been enough pain for those using the Plasma LTS to change something. Possibly because

Re: 2 kirigami fixes for a point release

On 2/17/20 11:08 PM, Luca Beltrame wrote: In data martedì 18 febbraio 2020 04:03:05 CET, Nate Graham ha scritto: think KDE software should be presented to users. Basically, we acknowledge that Neon is already an actual OS--the "KDE OS"--and we Please don't suggest such downstre

Re: 2 kirigami fixes for a point release

On 2020-02-16 14:43, Albert Astals Cid wrote: Maybe i explain myself wrongly, i'm not blaming distros at all. They made a decision, we/I may agree with them or not, that's *my/our* problem, what I was disagreeing is to us having to do extra work because someone elses (the distros) decision.

Re: 2 kirigami fixes for a point release

On 2020-02-15 11:55, Ben Cooksley wrote: My point above was that the version you decide to freeze on should only be the version you depend on during development. The version you depend on when you release will be the next release of Frameworks (so by freezing on 5.66 for development, it should

Re: 2 kirigami fixes for a point release

On 2020-02-13 00:48, Kai Uwe Broulik wrote: To minimize potential Frameworks dependency problems I would even go as far as put Feature freeze on same date as Frameworks tagging date so that no new stuff goes in that could require a Framework change, like the wallpaper JPG vs PNG situation.

Re: 2 kirigami fixes for a point release

On 2020-02-13 00:42, Ben Cooksley wrote: A better way of approaching this would be to freeze the Frameworks version you are going to require API wise at an earlier point in the Plasma development cycle. This would allow for a full Frameworks release cycle to pass where bugs encountered during

Re: 2 kirigami fixes for a point release

[+ frameworks and plasma mailing lists] On 2020-02-12 11:31, Albert Astals Cid wrote: El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure: Personally I think it would be nice to have 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma users

Re: Frameworks 5.67 re-spin request

Merci beaucoup David! Nate On 2020-02-10 15:20, David Faure wrote: On lundi 10 février 2020 15:32:11 CET Nate Graham wrote: Hello frameworks packagers, I hate to have to make this request, bug could we get Frameworks 5.67 re-spun to include these two commits: https://cgit.kde.org

Frameworks 5.67 re-spin request

Hello frameworks packagers, I hate to have to make this request, bug could we get Frameworks 5.67 re-spun to include these two commits: https://cgit.kde.org/kirigami.git/commit/?id=f695cde36a6829b8b92b2fd82deff16d9385fcb9

Re: CI system maintainability

With regards to the discussion about mandatory code review, I think it's important to avoid immediately rushing to create new policy as a result of a particular event or abuse. It's always tempting to try to put in place a rule that would have avoided the problem if it had existed and was being

Re: KDE file dialog column resize no longer possible?

Yeah, go ahead and put it up on Phab! Nate On 1/18/19 1:56 PM, René J.V. Bertin wrote: Hi, Assistance would be appreciated. :-) I've whipped up something, a bit sneaky but it does more or less what I had in mind. - the QEvent::Polish handler connects to the sectionResized signal - this

Re: KDE file dialog column resize no longer possible?

Yes, this was an intentional change: https://cgit.kde.org/kio.git/commit/?id=e504bc1fd56412ee7e9748a0dfafa537977ec1b5 Check out the listed bugs that it fixed! However I understand that it did cause some fallout: https://bugs.kde.org/show_bug.cgi?id=401506 I tried to fix that in

Re: KDE file dialog column resize no longer possible?

Yes, this was an intentional change: https://cgit.kde.org/kio.git/commit/?id=e504bc1fd56412ee7e9748a0dfafa537977ec1b5 Check out the listed bugs that it fixed! However I understand that it did cause some fallout: https://bugs.kde.org/show_bug.cgi?id=401506 I tried to fix that in