This has now moved into https://invent.kde.org/plasma/plasma-login-manager
David
Yes, that is a full clean build after the build directory is configured
from scratch. The dependencies are prepared before that, and this is just
the time to run ninja which lists 4900 build steps or so (I can't
remember). I mean, the build isn't exactly very fast even on a reasonably
high-end syst
Hi,
Are these servers running multiple builds at a time, or is a Windows build
given the full host resources, i.e. 8c/16t and 64GB of RAM? If you can
monitor the resources in real time, it would be interesting to confirm if
indeed the CPU utilization is significantly lower than 100%, meaning
someth
>> Another point that requires extra build time for Krita is an
inappropriate timeout on 100 minutes. A lot of our windows builds are
terminated at around 95% completion because of this timeout, so we have to
rerun them and, effectively, consume more and more CI time.
>Have you got a list of these
> This is probably at least in part due to Windows on Docker having
extremely poor file system performance even vs. straight NTFS (which isn't
great to begin with).
Well, Krita builds on a normal Windows system are also quite slow (at least
much slower than on Linux). Though they are still much fa
On Tue, 2025-04-22 at 07:15 +1200, Ben Cooksley wrote:
> On Tue, Apr 22, 2025 at 5:57 AM Dmitry Kazakov
> wrote:
> > Hi, Ben!
> >
>
>
> Hey Dmitry,
>
> >
> > As for Krita, most of CI time is spent on the Windows pipeline,
> > which build extremely slowly due to done obscure filesystem issues
Hi, Ben!
As for Krita, most of CI time is spent on the Windows pipeline, which build
extremely slowly due to done obscure filesystem issues (searching includes
is extremely slow). I personally don't know how to fix it. I tried: 1) PCH
builds, 2) relative includes, 3) split debug info (dwo). The on
On Tue, Apr 22, 2025 at 10:53 PM Maciej Jesionowski
wrote:
> Yes, that is a full clean build after the build directory is configured
> from scratch. The dependencies are prepared before that, and this is just
> the time to run ninja which lists 4900 build steps or so (I can't
> remember). I mean,
On Tue, Apr 22, 2025 at 10:44 PM Konstantin Kharlamov
wrote:
> On Tue, 2025-04-22 at 07:15 +1200, Ben Cooksley wrote:
> > On Tue, Apr 22, 2025 at 5:57 AM Dmitry Kazakov
> > wrote:
> > > Hi, Ben!
> > >
> >
> >
> > Hey Dmitry,
> >
> > >
> > > As for Krita, most of CI time is spent on the Windows p
On Tue, Apr 22, 2025 at 9:53 AM Maciej Jesionowski wrote:
> Hi,
>
Hi Maciej,
> Are these servers running multiple builds at a time, or is a Windows build
> given the full host resources, i.e. 8c/16t and 64GB of RAM? If you can
> monitor the resources in real time, it would be interesting to co
On Tue, Apr 22, 2025 at 5:57 AM Dmitry Kazakov wrote:
> Hi, Ben!
>
Hey Dmitry,
>
> As for Krita, most of CI time is spent on the Windows pipeline, which
> build extremely slowly due to done obscure filesystem issues (searching
> includes is extremely slow). I personally don't know how to fix i
On Sun, Apr 20, 2025 at 8:26 AM Ben Cooksley wrote:
> On Sun, Apr 20, 2025 at 1:50 AM Linus Jahn wrote:
>
>> On Sat, 19 Apr 2025 13:23:59 +0100
>> David Edmundson wrote:
>>
>> > >Realistically merge requests shouldn't be proposed until people are
>> > >ready to get something reviewed and merged
On Sun, Apr 20, 2025 at 9:10 PM Albert Astals Cid wrote:
> El divendres, 18 d’abril del 2025, a les 21:25:36 (Hora d’estiu d’Europa
> central), Ben Cooksley va escriure:
> > Hi all,
> >
> > Over the past week or two there have been a number of complaints
> regarding
> > CI builder availability wh
El divendres, 18 d’abril del 2025, a les 21:25:36 (Hora d’estiu d’Europa
central), Ben Cooksley va escriure:
> Hi all,
>
> Over the past week or two there have been a number of complaints regarding
> CI builder availability which i've done some investigating into this
> morning.
>
> Part of this
El dissabte, 19 d’abril del 2025, a les 10:47:13 (Hora d’estiu d’Europa
central), Ben Cooksley va escriure:
> On Sat, Apr 19, 2025 at 7:25 AM Ben Cooksley wrote:
> > Hi all,
> >
> > Over the past week or two there have been a number of complaints regarding
> > CI builder availability which i've
On Fri, Apr 18, 2025 at 3:26 PM Ben Cooksley wrote:
>
>
> When reviewing the list of CI builds projects have enabled, it is important
> to consider to what degree your project benefits from having various builds
> enabled. One common pattern i've seen is having Alpine, SUSE Qt 6.9 and SUSE
> Qt
On Samstag, 19. April 2025 21:29:07 Mitteleuropäische Sommerzeit Ben Cooksley
wrote:
> On Sun, Apr 20, 2025 at 7:21 AM Ingo Klöcker wrote:
> > Sounds like we shouldn't be so trigger-happy clicking the Rebase button on
> > our
> > MRs when it's not really necessary. We could rebase locally and the
On Sun, Apr 20, 2025 at 1:50 AM Linus Jahn wrote:
> On Sat, 19 Apr 2025 13:23:59 +0100
> David Edmundson wrote:
>
> > >Realistically merge requests shouldn't be proposed until people are
> > >ready to get something reviewed and merged in...
> >
> > That's not realistic with how it is on the fron
On Sun, Apr 20, 2025 at 12:24 AM David Edmundson
wrote:
> >Realistically merge requests shouldn't be proposed until people are ready
> to get something reviewed and merged in...
>
> That's not realistic with how it is on the frontlines. The earlier we
> share feedback the better, and reviews can
On Sun, Apr 20, 2025 at 7:21 AM Ingo Klöcker wrote:
> On Samstag, 19. April 2025 10:33:45 Mitteleuropäische Sommerzeit Ben
> Cooksley
> wrote:
> > A big part of the issue here is our rebase centric workflow - normally
> with
> > Gitlab you use merge commits and in this workflow CI only runs when
On Samstag, 19. April 2025 10:33:45 Mitteleuropäische Sommerzeit Ben Cooksley
wrote:
> A big part of the issue here is our rebase centric workflow - normally with
> Gitlab you use merge commits and in this workflow CI only runs when the MR
> changes.
> With a rebase workflow like ours though, othe
On Sun, Apr 20, 2025 at 3:19 AM Akseli Lahtinen wrote:
> On Friday 18 April 2025 22:25:36 Eastern European Summer Time Ben Cooksley
> wrote:
> > Hi all,
> >
> > Over the past week or two there have been a number of complaints
> regarding
> > CI builder availability which i've done some investigat
On Sat, Apr 19, 2025 at 11:47 AM Ben Cooksley wrote:
>
> - FreeBSD Qt 6.9 monitors buildability on BSD libc + Clang + Qt 6.9
FreeBSD is at Qt 6.8 at the moment. We're close to updating to 6.9 though.
On Friday 18 April 2025 22:25:36 Eastern European Summer Time Ben Cooksley
wrote:
> Hi all,
>
> Over the past week or two there have been a number of complaints regarding
> CI builder availability which i've done some investigating into this
> morning.
>
Hi, is there a possibility we don't run
Am Samstag, 19. April 2025, 10:33:45 Mitteleuropäische Sommerzeit schrieb Ben
Cooksley:
> > Not sure what we can do about kwin. I looked how we can reduce the time
> > needed to run tests, and there's not much space for improvements anymore. >
> > >
Speaking for kwin, I personally wouldn't mind
>Realistically merge requests shouldn't be proposed until people are ready to
>get something reviewed and merged in...
That's not realistic with how it is on the frontlines. The earlier we
share feedback the better, and reviews can take many many iterations.
There's a "CI_MERGE_REQUEST_APPROVED"
On Sat, Apr 19, 2025 at 7:25 AM Ben Cooksley wrote:
> Hi all,
>
> Over the past week or two there have been a number of complaints regarding
> CI builder availability which i've done some investigating into this
> morning.
>
> Part of this is related to the Windows CI builders falling offline due
On Sat, Apr 19, 2025 at 8:05 PM laurent Montel wrote:
> Le vendredi 18 avril 2025, 21:25:36 heure d’été d’Europe centrale Ben
> Cooksley a écrit :
> > Hi all,
>
> > Ruqola: Appears to be conducting a development process whereby changes
> are
> > made in stable then immediately merged to master in
On Sat, Apr 19, 2025 at 8:07 PM Vlad Zahorodnii
wrote:
> On 4/19/25 10:53 AM, Kai Uwe Broulik wrote:
> > Hi,
> >
> > thanks for looking into this.
> >
> > It seems a major contributor to CI time is the fact that a merge
> > request runs and once merged, master runs another pretty much
> > identic
On 4/19/25 10:53 AM, Kai Uwe Broulik wrote:
Hi,
thanks for looking into this.
It seems a major contributor to CI time is the fact that a merge
request runs and once merged, master runs another pretty much
identical pipeline right after that.
As for KWin: Not sure which one we could axe. KWi
Le vendredi 18 avril 2025, 21:25:36 heure d’été d’Europe centrale Ben Cooksley
a écrit :
> Hi all,
> Ruqola: Appears to be conducting a development process whereby changes are
> made in stable then immediately merged to master in a ever continuing loop.
> Please discontinue this behaviour and onl
Hi,
thanks for looking into this.
It seems a major contributor to CI time is the fact that a merge request
runs and once merged, master runs another pretty much identical pipeline
right after that.
As for KWin: Not sure which one we could axe. KWin uses a bunch of
internal Qt stuff, so catc
Am 26.03.25 um 15:28 schrieb David Edmundson:
I'd lean towards merging them in one repo. Neither are useful on their own, are
they?
Only benefit is the ability to change the backend in the future
without a messy git history.
I wouldn't worry too much about that since it's rather hypothetical.
This has now been done.
https://invent.kde.org/davidedmundson/plasma-login-manager is now the
main branch and contains all code including the backend, greeter and
KCM.
I'll start a proper review process with the goal of being ready for Plasma 6.5
David
>I wouldn't worry too much about that since it's rather hypothetical.
Now you're just crushing all my dreams!
But you're right, I'll merge all into plasma-login-manager and go from there.
David
On Fri, Mar 28, 2025 at 10:19 AM Paul Brown wrote:
>
> On Wednesday, 26 March 2025 10:25:30 Central European Standard Time David
> Edmundson wrote:
> > As discussed in Plasma meetings and Akademy's, Oliver Beard and I have
> > been working on incubating SDDM into Plasma whilst also providing a
> >
On Wednesday, 26 March 2025 10:25:30 Central European Standard Time David
Edmundson wrote:
> As discussed in Plasma meetings and Akademy's, Oliver Beard and I have
> been working on incubating SDDM into Plasma whilst also providing a
> more coherent Plasma experience.
>
> This has been implemente
>
> I'd lean towards merging them in one repo. Neither are useful on their own,
> are they?
Only benefit is the ability to change the backend in the future
without a messy git history.
> Then it probably makes sense to move the repo(s) to the plasma namespace.
Yeah, will do once we know where w
Am 26.03.25 um 10:25 schrieb David Edmundson:
As discussed in Plasma meetings and Akademy's, Oliver Beard and I have
been working on incubating SDDM into Plasma whilst also providing a
more coherent Plasma experience.
This has been implemented as two new repositories:
https://invent.kde.org/dav
On Tue, Mar 25, 2025 at 9:26 AM Marc Jantzen wrote:
>
> Hi KDE Plasma Team,
> I’m running KDE Plasma on Ubuntu 24.04.1 with Qt 5.15.13, and I’ve
> noticed an odd thing: the qtvirtualkeyboard-plugin is in the repos (I
> can install it), but it doesn’t seem accessible or functional after
> logging i
El dimarts, 11 de març del 2025, a les 16:13:10 (Hora estàndard d’Europa
central), Jonathan Riddell va escriure:
> https://kde.org/announcements/plasma/6/6.3.3/
>
> Please note I will step down from Plasma release management after the 6.3
> series
Thanks for your work as Plasma release manager f
I don't have capacity to fix this
On Wed, 12 Mar 2025 at 01:20, Devin wrote:
> kwin appears to have PROJECT_VERSION still set to 6.3.2 in its
> CMakeLists.txt
>
> This causes building plasma-mobile to fail because it needs kwin 6.3.3
>
> Thanks,
> Devin
>
> On Tue, Mar 11, 2025 at 11:30 AM Carl
On Wednesday, 12 March 2025 08:52:44 Central European Standard Time David
Redondo wrote:
> Hi,
>
> Jonathan announced that he will step back from doing Plasma releases.
> This means for 6.4 and forward we need someone else to do releases
> or multiple persons that share the work (didn't quite wo
On Tuesday, 11 March 2025 16.13.10 Central European Standard Time Jonathan
Riddell wrote:
> https://kde.org/announcements/plasma/6/6.3.3/
>
> Please note I will step down from Plasma release management after the 6.3
> series
Thank you for this all those years
--
Marco Martin
Am Dienstag, 11. März 2025, 16:13 schrieb Jonathan Riddell:
> https://kde.org/announcements/plasma/6/6.3.3/
>
> Please note I will step down from Plasma release management after the 6.3
> series
>
Thank you Jonathan for doing it all these years.
David
kwin appears to have PROJECT_VERSION still set to 6.3.2 in its
CMakeLists.txt
This causes building plasma-mobile to fail because it needs kwin 6.3.3
Thanks,
Devin
On Tue, Mar 11, 2025 at 11:30 AM Carl Schwan wrote:
> On Tue, Mar 11, 2025, at 4:13 PM, Jonathan Riddell wrote:
> > https://kde.or
On Tue, Mar 11, 2025, at 4:13 PM, Jonathan Riddell wrote:
> https://kde.org/announcements/plasma/6/6.3.3/
>
> Please note I will step down from Plasma release management after the 6.3
> series
Thank you for your great work all these years!
On Fri, Feb 14, 2025 at 1:46 AM Harald Sitter wrote:
> If people are up for it you can also arrive a day early and/or late and I can
> take you on a bit of a tour through Graz. Drop me an email if you are
> interested. Don't be shy :)
Sightseeing will be on the 27th.
HS
Hi,
> We graciously get the meeting rooms provided by the people of Grazer
> Linuxtage, a FOSS event that is happening on Saturday. As a thank you it'd
> be cool if we could do a booth on Saturday. Just need a couple people so we
> can staff for an hour or two each. Please reach out to me.
I can h
pectacle-6.3.2.1
1.4MB
-
12362c0e4b01b405f8be68b4d4b59fb92082784eaa69c212f0c5106470e6
+
df1d33ebab501ef4bf658d4c894a870c3fe648bd836c5fc5ee20587cde093cee
I'd like to propose we (KDE) take a look at our release process, QA and
testing. In the last few weeks we've had 4 re-spins after release.
Are these re
Kwin update
- http://download.kde.org/stable/plasma/6.3.2/kwin-6.3.2.tar.xz
">kwin-6.3.2
+ http://download.kde.org/stable/plasma/6.3.2/kwin-6.3.2.1.tar.xz
">kwin-6.3.2.1
8.4MB
-
3655980d5ecd80e0c59d7330c010632c1dbd4857e9c3c326f2e31520afea9ca3
+
e6123eda2b1fd9f65b36061fdacf96234068d1e2
Spectacle update
- http://download.kde.org/stable/plasma/6.3.2/spectacle-6.3.2.tar.xz
">spectacle-6.3.2
+ http://download.kde.org/stable/plasma/6.3.2/spectacle-6.3.2.1.tar.xz
">spectacle-6.3.2.1
1.4MB
-
12362c0e4b01b405f8be68b4d4b59fb92082784eaa69c212f0c5106470e6
+
df1d33ebab501ef4
On Friday, 21 February 2025 15:59:12 Central European Standard Time David
Redondo wrote:
> Am Freitag, 14. Februar 2025, 01:46 schrieb Harald Sitter:
> > Hello again, hello!
>
> Hi,
>
> > [snip]
> > We graciously get the meeting rooms provided by the people of Grazer
> > Linuxtage, a FOSS event
Am Freitag, 14. Februar 2025, 01:46 schrieb Harald Sitter:
> Hello again, hello!
>
Hi,
> [snip]
> We graciously get the meeting rooms provided by the people of Grazer
> Linuxtage, a FOSS event that is happening on Saturday. As a thank you it'd
> be cool if we could do a booth on Saturday. Just n
> seems) due to C++ funkiness. They fixed it, and I cherry-picked it to
> > > 6.3. Can we get a respin or a 6.3.1.1? Thanks!
> >
> > If it only affects two distros, I think having them carrying the patch
> > downstream is more suitable than re-spinning (something in
gt; 6.3. Can we get a respin or a 6.3.1.1? Thanks!
>
> If it only affects two distros, I think having them carrying the patch
> downstream is more suitable than re-spinning (something in my opinion we
> should never do) or creating a new tarball, e.g. 6.3.1.1.
I thought about this, but
done
On Tue, 18 Feb 2025 at 23:56, Joshua Goins wrote:
> Someone noticed a build failure on some systems (NixOS and Slackware it
> seems)
> due to C++ funkiness. They fixed it, and I cherry-picked it to 6.3. Can we
> get
> a respin or a 6.3.1.1? Thanks!
>
> https://invent.kde.org/plasma/plasma-
two distros, I think having them carrying the patch
downstream is more suitable than re-spinning (something in my opinion
we should never do) or creating a new tarball, e.g. 6.3.1.1.
What is different about these two distros that only they were affected?
Perhaps it is something we can add tests
patch
downstream is more suitable than re-spinning (something in my opinion we
should never do) or creating a new tarball, e.g. 6.3.1.1.
What is different about these two distros that only they were affected?
Perhaps it is something we can add tests or CI jobs for.
Justin
Am Donnerstag, 23. Januar 2025, 11:07 schrieb Martin Riethmayer:
> Hi all,
>
> I've drafted a schedule for 6.4 at
>
> https://community.kde.org/Schedules/Plasma_6#Future_releases
>
> Things I tried to consider:
>
> - 3 releases per year - this should put the release of 6.4. around 4
> months a
And done, enabled some of the CIs too for good measure.
Happy typing!
Aleix
On Tue, Feb 4, 2025 at 11:06 PM Aleix Pol wrote:
>
> Thanks Ben!
>
> We're officially all adults now. We can all sit down on our recliners
> and smoke our pipe thinking of the good old days. :D
>
> Cheers!
> Aleix
>
> PS
Thanks Ben!
We're officially all adults now. We can all sit down on our recliners
and smoke our pipe thinking of the good old days. :D
Cheers!
Aleix
PS: I'll try to go through the code renaming all qvk mentions today or so
On Tue, Feb 4, 2025 at 9:55 AM Marco Martin wrote:
>
> On Tuesday, 4 F
On Tuesday, 4 February 2025 03.08.38 Central European Standard Time Aleix Pol
wrote:
> After talking with many people, I've the feeling that everyone gets
> super excited about "klickyklacky" and then agrees that a boring
> "plasma-keyboard" will make our collective lives easier, so I'll go
> wit
On Tue, Feb 4, 2025 at 3:08 PM Aleix Pol wrote:
> On Fri, Jan 24, 2025 at 6:44 PM David Edmundson
> wrote:
> >
> > > The responsible people from the input team mentioned to me that they
> > > wanted to work on it but I guess not under the apol namespace, so I
> > > was asked to have it moved, I
On Fri, Jan 24, 2025 at 6:44 PM David Edmundson
wrote:
>
> > The responsible people from the input team mentioned to me that they
> > wanted to work on it but I guess not under the apol namespace, so I
> > was asked to have it moved, I requested it to move into plasma's
> > namespace.
> > https://
> Disclaimers: I always understood the repository and "soft feature"
> freeze to be an Alpha release
No, we want to make sure there's no super-duper big changes happening
around the same time
that someone is trying to make tarballs and packages. It gets messy,
things might not even compile or log
> The responsible people from the input team mentioned to me that they
> wanted to work on it but I guess not under the apol namespace, so I
> was asked to have it moved, I requested it to move into plasma's
> namespace.
> https://invent.kde.org/plasma/qvk
Is it in a state ready to start the whole
An update to plasma-desktop is now available
http://download.kde.org/unstable/plasma/6.2.91/plasma-desktop-6.2.91.1.tar.xz
sha256 bd877e277a1937d893ba30155fce8c7d1aa491e0ecdf929930298017cfc6542f
On Thu, 23 Jan 2025 at 17:10, Jonathan Riddell wrote:
>
> Plasma 6.3 beta 2 is available for testing
Am 21.01.25 um 23:40 schrieb Aleix Pol:
Hi folks,
As you know, I was working on a QtVirtualKeyboard-based Wayland
keyboard around last summer.
The responsible people from the input team mentioned to me that they
wanted to work on it but I guess not under the apol namespace, so I
was asked to hav
I love the name klickyklacky. It oozes personality and fun, while still making
sense.
Though I would propose clickyklacky just so that all our apps don't start with
"k" :)
Best regards,
- Akseli
Thanks Aleix!
+1 for klavier or klickyklacky, depending on how silly we want to go. :)
Nate
On 1/21/25 3:40 PM, Aleix Pol wrote:
Hi folks,
As you know, I was working on a QtVirtualKeyboard-based Wayland
keyboard around last summer.
The responsible people from the input team mentioned to me
On 22/1/25 09:10, Aleix Pol wrote:
Hi folks,
As you know, I was working on a QtVirtualKeyboard-based Wayland
keyboard around last summer.
The responsible people from the input team mentioned to me that they
wanted to work on it but I guess not under the apol namespace, so I
was asked to have it
On Sat, Jan 18, 2025 at 12:59 AM Carl Schwan wrote:
> On Thu, Dec 5, 2024, at 4:53 PM, Noah Davis wrote:
> > Hello everyone, I would like to propose moving Spectacle to the Plasma
> > development release schedule. It already depends heavily on Plasma for
> > its core functionality. When a Plasma
On Thu, Dec 5, 2024, at 4:53 PM, Noah Davis wrote:
> Hello everyone, I would like to propose moving Spectacle to the Plasma
> development release schedule. It already depends heavily on Plasma for
> its core functionality. When a Plasma bug or feature happens on a new
> release that affects Spectac
On Tue, Jan 14, 2025 at 9:47 PM Marco Martin wrote:
> On Wednesday, 8 January 2025 15.17.03 Central European Standard Time David
> Edmundson wrote:
> > > The first Beta is tomorrow. So I think we just go with 6.7?
> >
> > At this point, yes.
>
> so far i seen in the taskmanager applet a property
On Wednesday, 8 January 2025 15.17.03 Central European Standard Time David
Edmundson wrote:
> > The first Beta is tomorrow. So I think we just go with 6.7?
>
> At this point, yes.
so far i seen in the taskmanager applet a property on Image only present in
6.8 is used
--
Marco Martin
Hello everyone,
I need to know the status of this review so I can get it included in
Plasma 6.3!
Thank you for your time,
Scarlett
On 11/25/24 11:15, Soumyadeep Ghosh wrote:
Hi team,
I created a KCM for managing snap permissions. It has been through
incubation and this is a request for th
An update to this has been published to fix a failed compile in translations
c36d94bf3f15ba00c27847d492cd58410ad4e03cd8be2b0c06d71e371c30dd1c
http://download.kde.org/stable/plasma/5.27.12/plasma-sdk-5.27.12.1.tar.xz
My apologies, that should of course be Plasma 6.3 beta
On Fri, Jan 10, 2025 at 5:26 AM Nicolas Fella wrote:
> Am 09.01.25 um 17:20 schrieb Volker Krause:
> > On Donnerstag, 9. Januar 2025 11:12:09 Mitteleuropäische Normalzeit David
> > Redondo wrote:
> >> Am Mittwoch, 8. Januar 2025, 17:18 schrieb Nicolas Fella:
> >>> Am 08.01.25 um 10:57 schrieb Dav
Am 09.01.25 um 17:20 schrieb Volker Krause:
On Donnerstag, 9. Januar 2025 11:12:09 Mitteleuropäische Normalzeit David
Redondo wrote:
Am Mittwoch, 8. Januar 2025, 17:18 schrieb Nicolas Fella:
Am 08.01.25 um 10:57 schrieb David Redondo:
Hi,
the original plan for Plasma 6.3 was to require Qt 6.8
On Donnerstag, 9. Januar 2025 11:12:09 Mitteleuropäische Normalzeit David
Redondo wrote:
> Am Mittwoch, 8. Januar 2025, 17:18 schrieb Nicolas Fella:
> > Am 08.01.25 um 10:57 schrieb David Redondo:
> > > Hi,
> > >
> > > the original plan for Plasma 6.3 was to require Qt 6.8 (as the wiki
> > > curr
Am Mittwoch, 8. Januar 2025, 17:18 schrieb Nicolas Fella:
> Am 08.01.25 um 10:57 schrieb David Redondo:
> > Hi,
> >
> > the original plan for Plasma 6.3 was to require Qt 6.8 (as the wiki
> > currently
> > notes). However FreeBSD so far didn't gain Qt 6.7 and we never bumped it.
> > The first Beta
On Wed, Jan 8, 2025, at 6:24 PM, Nate Graham wrote:
> On 1/3/25 8:17 AM, Nicolas Fella wrote:
> > Am 30.12.24 um 18:51 schrieb Nate Graham:
> >> A long term concern I have is that it's messy and unpleasant to have
> >> default styling data scattered across so many places. Ideally we'd be
> >> able
On 1/3/25 8:17 AM, Nicolas Fella wrote:
Am 30.12.24 um 18:51 schrieb Nate Graham:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single
repo, so
On 12/31/24 4:59 AM, Ingo Klöcker wrote:
On Montag, 30. Dezember 2024 18:51:39 Mitteleuropäische Normalzeit Nate Graham
wrote:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data
Am 08.01.25 um 10:57 schrieb David Redondo:
Hi,
the original plan for Plasma 6.3 was to require Qt 6.8 (as the wiki currently
notes). However FreeBSD so far didn't gain Qt 6.7 and we never bumped it.
The first Beta is tomorrow. So I think we just go with 6.7?
David
I am rather annoyed that thi
Eww… I made libplasma depend on some Qt 6.8 functionality because the
wiki said it’s gonna be Qt 6.8. :-(
Am 08.01.25 um 15:17 schrieb David Edmundson:
The first Beta is tomorrow. So I think we just go with 6.7?
At this point, yes.
David
> The first Beta is tomorrow. So I think we just go with 6.7?
At this point, yes.
David
The checklist isn't complete for starters.
On Mon, Dec 30, 2024 at 4:29 PM Scarlett Moore <
scarlett.gately.mo...@gmail.com> wrote:
> Hello everyone,
>
> I need to know the status of this review so I can get it included in
> Plasma 6.3!
>
> Thank you for your time,
>
> Scarlett
> On 11/25/24 11:1
On Sunday, 5 January 2025 13.59.41 Central European Standard Time David
Redondo wrote:
> Hi,
>
> > > 2025-01-09 Beta
> > > Thu 2025-01-23 Beta 2
> > > Thu 2025-02-06 Tars
> > > Tue 2025-02-11 Release
> >
> > The options would be:
> >
> > Three days before beta:
> > 6th Jan, 20th Jan, 3rd Feb
On Monday, 30 December 2024 18.51.39 Central European Standard Time Nate
Graham wrote:
> A long term concern I have is that it's messy and unpleasant to have
> default styling data scattered across so many places. Ideally we'd be
> able to centralize *all* data about a particular style in a single
Hi,
> > 2025-01-09 Beta
> > Thu 2025-01-23 Beta 2
> > Thu 2025-02-06 Tars
> > Tue 2025-02-11 Release
>
> The options would be:
>
> Three days before beta:
> 6th Jan, 20th Jan, 3rd Feb
>
> A week before beta:
> 13th Jan, 27th Jan, 10th Feb
>
I've decided on 13th for the simple reason that I
Am 30.12.24 um 18:51 schrieb Nate Graham:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single
repo, so that making changes is easy and that rep
El dilluns, 16 de desembre del 2024, a les 19:19:14 (Hora estàndard del Centre
d’Europa), Noah Davis va escriure:
> No, in a previous email on this thread, I decided it actually wouldn't
> be very difficult to maintain 24.12 and 6.3 at the same time.
Ok, Spectacle removed from KDE Gear future rel
On Montag, 30. Dezember 2024 18:51:39 Mitteleuropäische Normalzeit Nate Graham
wrote:
> A long term concern I have is that it's messy and unpleasant to have
> default styling data scattered across so many places. Ideally we'd be
> able to centralize *all* data about a particular style in a single
Hi,
On 2024-12-30 21:58, Nate Graham wrote:
On 12/30/24 12:31 PM, christ...@cullmann.io wrote:
On 2024-12-30 18:51, Nate Graham wrote:
I see an opportunity to move closer to that here. So my preference
would be to implement the proposal, but also:
- the default window decorations remain in Br
On 12/30/24 12:31 PM, christ...@cullmann.io wrote:
On 2024-12-30 18:51, Nate Graham wrote:
I see an opportunity to move closer to that here. So my preference
would be to implement the proposal, but also:
- the default window decorations remain in Breeze
- the default colors remain in Breeze, an
Hi,
On 2024-12-30 18:51, Nate Graham wrote:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single
repo, so that making changes is easy and tha
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single repo,
so that making changes is easy and that repo can be swapped out for
another one in
1 - 100 of 44572 matches
Mail list logo
