Plasma 6.1 tars are due on Thu 13 June and release Tue 18 June. I'm
going to be away on holiday paddling under the midnight sun in Norwary
during this time. Would anyone else like to be release manager?
Jonathan
Hi Dan, can I make a plasma pass release so that it builds with Plasma 6?
Jonathan
Am Mittwoch, 7. Februar 2024, 10:37:13 CET schrieb Kai Uwe Broulik:
> Hi,
>
> plasma-integration already (which I am NOT happy about!) creates a GL
> context to check whether to use software rendering, there we could also
> check the GL_VENDOR and set basic render loop.
>
Yes we did that in 5
Hi,
plasma-integration already (which I am NOT happy about!) creates a GL
context to check whether to use software rendering, there we could also
check the GL_VENDOR and set basic render loop.
But backporting won’t hurt either way I’d say.
Cheers
Kai Uwe
Am 07.02.24 um 10:13 schrieb David
Hi,
when using Wayland on Nvidia there is a significant problem that QtQuick
windows freeze when resized, this can also manifest in plasma popups sometimes
not showing up.
ref. https://bugreports.qt.io/browse/QTBUG-95817
This can be worked around with using the basic render loop instead of the
That's on my todo for today :)
Jonathan
On Mon, 6 Nov 2023 at 21:55, Neal Gompa wrote:
> On Mon, Nov 6, 2023 at 11:21 AM Jonathan Riddell wrote:
> >
> > Diff from 5.27
> > -aura-browser
> > -aura-browser
> > +kactivities
> > +kactivities-stats
> > -khotkeys
> > -krdp
> > +kwayland
> >
On Mon, Nov 6, 2023 at 11:21 AM Jonathan Riddell wrote:
>
> Diff from 5.27
> -aura-browser
> -aura-browser
> +kactivities
> +kactivities-stats
> -khotkeys
> -krdp
> +kwayland
> -plank-player
> -plank-player
> -plasma-bigscreen
> +plasma-framework
> -plasma-remotecontrollers
> +plasma5support
>
Good point, I've added in kglobalacceld now
Jonathan
On Mon, 6 Nov 2023 at 17:51, Antonio Rojas wrote:
> El lunes, 6 de noviembre de 2023 17:21:06 (CET) Jonathan Riddell escribió:
>
> > Diff from 5.27
>
> Hi,
>
> What about kglobalacceld?
>
>
>
>
>
El lunes, 6 de noviembre de 2023 17:21:06 (CET) Jonathan Riddell escribió:
> Diff from 5.27
Hi,
What about kglobalacceld?
Diff from 5.27
-aura-browser
-aura-browser
+kactivities
+kactivities-stats
-khotkeys
-krdp
+kwayland
-plank-player
-plank-player
-plasma-bigscreen
+plasma-framework
-plasma-remotecontrollers
+plasma5support
+print-manager
+wacomtablet
Complete list:
bluedevil
breeze
breeze-grub
breeze-gtk
On Tue, Sep 26, 2023 at 12:29 AM Albert Astals Cid wrote:
>
> El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va
> escriure:
> > https://community.kde.org/Schedules/February_2024_MegaRelease
> >
> > Beta 1 is during Qt World Summit that is not ideal but I guess doable?
inters.
> >>
> >> Given no one did seem to oppose so far, I would consider to switch
> >> Kate to Qt
> >> 6 in master next Wednesday and start the bit Qt 6 run :)
> >
> > When you switch a branch to qt6, please remember to ping the
> > translati
ot;, "stable": "none", "stable_kf5": "release/23.08",
"trunk_kf5": "master"}
Would it be something like:
{"trunk": "master", "stable": "none", "stable_kf5": "release/23.08",
"trunk_kf5": "none"}
Greetings
Christoph
christ...@cullmann.io ha scritto:
> On 2023-09-05 23:08, Albert Astals Cid wrote:
>> El dimarts, 5 de setembre de 2023, a les 22:42:13 (CEST),
>> christ...@cullmann.io va escriure:
>>> On 2023-09-04 22:59, Albert Astals Cid wrote:
>>> > El dilluns, 4 de setembre de 2023, a les 18:50:45 (CEST),
e the i18n branch information
Anything else I am missing?
Hi,
Thanks for the additional pointers.
Given no one did seem to oppose so far, I would consider to switch Kate
to Qt 6 in master next Wednesday and start the bit Qt 6 run :)
(If nothing comes up here)
The everybody had a week to chi
://invent.kde.org/utilities/kate/-/blob/master/.gitlab-ci.yml?ref_type=heads
and require KF 6 + Qt 6 in the CMake files or is there additional stuff
that
needs updates to avoids one breaks stuff?
Greetings
Christoph
- The KDE Gear release will move by 2 months to allow for the extra
time needed
info
But this is autogenerated by Nico scripts nowadays so... maybe not? or prod
him to run the script?
projects/*/*/i18n.json
to update the i18n branch information
Anything else I am missing?
Cheers,
Albert
>
> Greetings
> Christoph
>
> >> - The KDE Gear rel
er will be open for Qt6 code to land for those
> ready to move. Not all apps need to port.
For the trigger happy among us...
This is a plan/proposal, let's give people at least one week to comment/
disagree on it before making master Qt6-only for Gear apps.
>
> - The KDE Gear release will m
Following on from the last Akademy we checked where we were with our
development progress in a meeting and settled on the following plan
for all 3 major parts:
- In KDE Gear master will be open for Qt6 code to land for those
ready to move. Not all apps need to port.
- The KDE Gear release
As a reminder this meeting is tonight in 3 hours.
David
Video call at https://meet.kde.org/b/ada-mi8-aem
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
A time has been chosen on the poll with a clear winner:
4th September 18:00 CEST
See you all there
David Edmundson
As discussed at Akademy we need to finalize the release of KF6 /
Applications with 6 and Plasma 6.
Applications can't release without Plasma (for Breeze + Plasma Integration)
Plasma is weakened without kio-extras
Both depend on Frameworks which needs a final release.
We want to be fairly synced
5.27.7 is scheduled for Tuesday August 8th. I'm away on adoption leave and
won't be available that day, the best I can do is say I might be able to
squeeze it in somewhere in the following two weeks. If anyone else wants
to do it let me know and I'll take you through how it's done.
Jonathan
). The former is a regression
introduced in 5.25.5. Instead of hoping distros will apply those
themselves I propose we make a 5.25.5.1 release for plasma-workspace.
Cheers
Nico
. Instead of hoping distros will apply those
themselves I propose we make a 5.25.5.1 release for plasma-workspace.
Cheers
Nico
Sounds good, thanks Jonathan!
Aleix
On Fri, May 6, 2022 at 12:56 PM Jonathan Riddell wrote:
>
> I'm proposing Tuesday July 5 for a 5.24.6LTS release. It's 11 weeks after
> the 5.24.5 release and is mostly timed to be useful to Kubuntu.
>
> Jonathan
>
>
> On Thu, 5 May
I'm proposing Tuesday July 5 for a 5.24.6LTS release. It's 11 weeks after
the 5.24.5 release and is mostly timed to be useful to Kubuntu.
Jonathan
On Thu, 5 May 2022 at 10:34, Jonathan Riddell wrote:
> Does anyone have a request for a release date for the next or following
> 5.
Does anyone have a request for a release date for the next or following
5.24 LTS releases?
I've had one from Kubuntu asking "the .6 is at least a few weeks to a month
before the 22.04.1 point release on August 4"
Any more?
Jonathan
Sensible enough, but the developers do need to follow Plasma's release
schedule then. Changing name after repo freeze shouldn't happen. Nor
should adding new dependencies or depending on versions of Frameworks newer
than our release specifies
https://invent.kde.org/plasma/plasma-mobile/-/commit
On Tue, Feb 8, 2022 at 3:21 PM Jonathan Riddell wrote:
>
> plasma-phone-components is released as part of Plasma which has an
> established release process that we review at the start of each cycle. This
> time it was renamed after the repo freeze and after the beta
plasma-phone-components is released as part of Plasma which has an
established release process that we review at the start of each cycle.
This time it was renamed after the repo freeze and after the beta which
causes unpredictable problems in the packaging process.
Should plasma-phone-components
5.23 during F35 Beta or F35 Final. A big
part of why I was comfortable with switching to Wayland by default[3]
for Fedora Linux 34 was that I was shipping the latest in-development
release at that time. Looking at the schedule now, we're basically
going to have to sit out of Plasma 5.23 like we did f
We discussed this some more, and we are not in favour of moving
forwards for Fedora:
Reasons given were:
- It either cuts into our beta period, or causes us issues with
framework releases.
- Fedora has regular releases anyway
- It collides with the promo plans above
- .0 releases tend to not
On Tuesday, 8 June 2021 15:59:37 CEST Nate Graham wrote:
> Hello release folks!
>
> Plasma 5.23 is currently scheduled to be released on 7 October. I've
> been talking with the Fedora packagers about this, and been informed
> that if we bump up the release by one week--shipping on
On Tuesday, 8 June 2021 14:59:37 BST Nate Graham wrote:
> Hello release folks!
>
> Plasma 5.23 is currently scheduled to be released on 7 October. I've
> been talking with the Fedora packagers about this, and been informed
> that if we bump up the release by one week-
Seems a friendly thing to do. We can discuss it during the kickoff session
at akademy.
Jonathan
On Tue, 8 Jun 2021 at 14:59, Nate Graham wrote:
> Hello release folks!
>
> Plasma 5.23 is currently scheduled to be released on 7 October. I've
> been talking with the Fedora pac
Hello release folks!
Plasma 5.23 is currently scheduled to be released on 7 October. I've
been talking with the Fedora packagers about this, and been informed
that if we bump up the release by one week--shipping on 31
September--then they can ship Plasma 5.23 in Fedora 35. Is this
something
eople, and find out which tasks are really blockers for KF 6.0 and which
> are not. In fact several Plasma items are not really blockers for KF6.
>
> In the worst case, the first plasma-frameworks release could be delayed
> until Plasma 6 is closer to be ready. Other frameworks don't depe
On sabato 17 aprile 2021 16:38:32 CEST Friedrich W. H. Kossebau wrote:
> It seems these days the only real user of plasma-frameworks & krunner
> libraries is the Plasma shell itself, with other applications only providing
> plugins/extensions and only targeting Plasma again. IIRC Amarok was the
>
> It seems these days the only real user of plasma-frameworks & krunner
> libraries is the Plasma shell itself, with other applications only providing
> plugins/extensions and only targeting Plasma again.
That is mostly in line with other discussions in plasma. There is a
ticket splitting
Hi,
sorry to bring this up again, but I would be in favor of a switching to 2
releases every year. I'd like to add some reasons to do that on the
promotional side:
1) In Promo, we are quite stepping up our game in the quality of
announcements, to both the website and the release video. We
in the quality of
> announcements, to both the website and the release video. We are already a
> bit stretched out with time, and having more of that to prepare each release
> would benefit us, especially if we intend - and I think we do - to improve
> our work even further.
I don't ag
of announcements,
to both the website and the release video. We are already a bit stretched out
with time, and having more of that to prepare each release would benefit us,
especially if we intend - and I think we do - to improve our work even further.
2)
We have measured that doing less
Hi,
sorry to bring this up again, but I would be in favor of a switching to 2
releases every year. I'd like to add some reasons to do that on the promotional
side:
1) In Promo, we are quite stepping up our game in the quality of
announcements, to both the website and the release
a week of
> each other, with relatively predictable release schedules.
> Unfortunately, new KDE/Plasma releases happen a little bit too late for them
> to
> be included in those distributions in time for the release. Thus the current
> version of KDE/Plamsa in both Fedora and Kubuntu is
We discussed this in the Plasma meeting on Monday and I'm afraid there's
little appetite in moving to a 6 monthly release or a 3 monthly release.
We did used to have a 3 monthly schedule but that is too tight given the
length of beta and freezes we want to have now. But also 6 monthly feels
too
On Thu, Nov 26, 2020 at 10:38 PM Neal Gompa wrote:
>
> On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol wrote:
> >
> > On Tue, Nov 24, 2020 at 5:10 PM David Edmundson
> > wrote:
> >>>
> >>> As distribution package maintainers, we would like Plasma
On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol wrote:
>
> On Tue, Nov 24, 2020 at 5:10 PM David Edmundson
> wrote:
>>>
>>> As distribution package maintainers, we would like Plasma developers to
>>> slightly alter the release schedule to align releases with a m
On Tue, Nov 24, 2020 at 5:10 PM David Edmundson
wrote:
> As distribution package maintainers, we would like Plasma developers to
>> slightly alter the release schedule to align releases with a more
>> distribution friendly cycle. You could consider shortening one release
>>
>
> As distribution package maintainers, we would like Plasma developers to
> slightly alter the release schedule to align releases with a more
> distribution friendly cycle. You could consider shortening one release
> cycle (and then keep the 6 month schedule) to align relea
Hi KDE/Plasma developers!
Nowadays, Fedora and Kubuntu make new releases twice a year within a week
of each other, with relatively predictable release schedules.
Unfortunately, new KDE/Plasma releases happen a little bit too late for
them to be included in those distributions in time
niedz., 24 maj 2020 o 20:17 Nate Graham wrote:
> Land it on Plasma/5.19, then manually merge Plasma/5.19 into master,
> same as before.
OK, thank you for confirmation.
--
Regards:
Konrad Materka
Materka wrote:
Hi,
What is the current procedure of merging fixes from release branch
back into master? For example I made a fix for Plasma/5.19 but I want
it in master as well. Merge Request from Plasma/5.19 into master has
conflicts, how to fix them in new GitLab flow?
Sorry if it was discussed
Hi,
What is the current procedure of merging fixes from release branch
back into master? For example I made a fix for Plasma/5.19 but I want
it in master as well. Merge Request from Plasma/5.19 into master has
conflicts, how to fix them in new GitLab flow?
Sorry if it was discussed already, but I
Beta on Thursday so please add features for the announce pronto.
https://share.kde.org/apps/files/?dir=/Community%20Notes/Plasma=1718757
(sort by modified date, edit Plasma 5.19.md)
or reply here
Jonathan
On vendredi 20 mars 2020 12:16:09 CET David Edmundson wrote:
> >> > Kirigami seems to be rather unstable, I wonder if anything can be done
> >> > to
> >> > improve upon that [*].
> >>
> >> One important thing seems to have been getting sloppy in those repos;
> >> mandatory code reviews.
> >>
>> > Kirigami seems to be rather unstable, I wonder if anything can be done to
>> > improve upon that [*].
>
>> One important thing seems to have been getting sloppy in those repos;
>> mandatory code reviews.
>> That's an easy thing to enforce, and we know it makes a huge difference to
>> code.
>>
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" arg
Frameworks release to
accompany the Plasma LTS release: to better support our non-Neon
downstreams who want to freeze on the Plasma LTS releases. Right now
we're pushing the job of backporting bugfixes to Frameworks onto them,
rather than making it easy by just giving them tarballs. We can ar
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? ;) I merely say that going "Neon or
else
solve the fundamental
> incompatibility between the Plasma LTS product, which is built around
> the release model of extended, ongoing bugfix releases, and Frameworks,
> which is built around a rolling release model with no bugfix releases at
> all.
I still don't see why this is a
; of KF, like non-workspace applications from KDE.
> >
Just to clarify something. "the Plasma team" is not unified in the
position that there should be any changes to the current framework's
release cycle.
> So perhaps we could say that the KF version which
happens to be the dep
here and maintain a matching LTS branch of Frameworks together at the
central KDE repos together. Well, and a version also satisfying other clients
of KF, like non-workspace applications from KDE.
It's not a reason to change normal KF release cycle.
I like that idea. So perhaps we could say that th
here and maintain a matching LTS branch of Frameworks together at the
central KDE repos together. Well, and a version also satisfying other clients
of KF, like non-workspace applications from KDE.
It's not a reason to change normal KF release cycle.
I like that idea. So perhaps we could say that th
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 downstream-hostile
am va
escriure:
> >> On another note, I have to admit I'm starting to doubt how well our LTS
> >> Plasma product works without a corresponding LTS frameworks release to
> >> support it. We can fix bugs in software that uses the Plasma release
> >> schedule till the cow
an ship to users of their own LTS releases.
>
> However all the autotests in the world will not resolve the fundamental
> incompatibility between the Plasma LTS product, which is built around
> the release model of extended, ongoing bugfix releases, and Frameworks,
> which is bui
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 downstream-hostile solutions, in particular because
this
tests are run before merging, etc. I think we can all agree
with that.
However all the autotests in the world will not resolve the fundamental
incompatibility between the Plasma LTS product, which is built around
the release model of extended, ongoing bugfix releases, and Frameworks,
which
ert Astals Cid wrote:
> > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va
> escriure:
> > >> On another note, I have to admit I'm starting to doubt how well our LTS
> > >> Plasma product works without a corresponding LTS frameworks release to
&
On Mon, Feb 17, 2020 at 10:43 AM Albert Astals Cid wrote:
>
> El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va
> escriure:
> > On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > > This is their fault, they as a distribution have decided to support a
> > >
El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va escriure:
> On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > This is their fault, they as a distribution have decided to support a random
> > KDE Frameworks version for longer than we do support it, so they
On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> This is their fault, they as a distribution have decided to support a random
> KDE Frameworks version for longer than we do support it, so they are the
> ones that should be the job of supporting it.
>
> It's like you are trying
El dissabte, 15 de febrer de 2020, a les 20:35:23 CET, Nate Graham va escriure:
> 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 depen
On Sun, Feb 16, 2020 at 8:35 AM Nate Graham wrote:
>
> 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
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
s would allow for a full Frameworks
> > release cycle to pass where bugs encountered during the lead up to the
> > Plasma release can be fixed.
> >
> > This version of Frameworks would then be the one that Plasma hard depends
> > on.
>
> We do this; Plasma 5
, and - surprise - cause problems all over the
stack which require a bunch of Frameworks fixes?
I agree, that should have been deferred to 5.19. Definitely a lack of
discipline on our behalf.
Another topic was the KUserFeedback KCM. There had been substantial
changes also on release date
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
, but if we want to take a firm
stance on this, I think we need to branch much earlier. "Soft" feature
freezes don't cut it. We should maybe branch two months before the
release rather than one.
Also, we can't branch Frameworks due to their inherently rolling nature.
Some of the regres
On Thu, Feb 13, 2020 at 5:40 PM Nate Graham wrote:
>
> Plasma 5.18 was a pretty buggy release, and I'd like to start a
> discussion about how we think it happened and what we can do better next
> time. Here are some of the top bugs that our users are reporting:
I think we wanted to
On 2020-02-13 11:55, Vlad Zahorodnii wrote:
On 2/13/20 8:11 PM, David Edmundson wrote:
I'm also seeing a rising amount of pushing without review on the core
repos. I would like for us all to (nicely) call that out if we see
any instances. Reviews are super important, the best time to fix a bug
On Thu, Feb 13, 2020 at 6:55 PM Vlad Zahorodnii wrote:
>
> On 2/13/20 8:11 PM, David Edmundson wrote:
> > I'm also seeing a rising amount of pushing without review on the core
> > repos. I would like for us all to (nicely) call that out if we see
> > any instances. Reviews are super important,
On 2/13/20 8:11 PM, David Edmundson wrote:
I'm also seeing a rising amount of pushing without review on the core
repos. I would like for us all to (nicely) call that out if we see
any instances. Reviews are super important, the best time to fix a bug
is before it even happens. Even for small
The important part right now is that we get on top with fixing them.
For 5.18 there was /wy/ too much feature pushing for this release.
Even if the new stuff itself doesn't introduce breakages, it takes
developer and review time away from what should be a month of being
totally on top
Plasma 5.18 was a pretty buggy release, and I'd like to start a
discussion about how we think it happened and what we can do better next
time. Here are some of the top bugs that our users are reporting:
- https://bugs.kde.org/show_bug.cgi?id=417424 [Can't enter edit mode if
widgets were
On jeudi 13 février 2020 09:46:20 CET David Edmundson wrote:
> > Kirigami seems to be rather unstable, I wonder if anything can be done to
> > improve upon that [*].
>
> One important thing seems to have been getting sloppy in those repos;
> mandatory code reviews.
> That's an easy thing to
eaking CI in the process)
> >
> > This means that other changes are likely being pushed into Frameworks
> > by Plasma with very little delay as well.
> >
> > Consequently this means stuff is landing in Framework repositories up
> > to the very moment it is released - a re
by Plasma with very little delay as well.
Consequently this means stuff is landing in Framework repositories up
to the very moment it is released - a release that the next version of
Plasma (LTS) then depends on.
A better way of approaching this would be to freeze the Frameworks
version you are going
eta feature freeze to be super strict, and even
had release people do a "soft feature freeze" even before that.
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
lly I think it would be nice to have
> >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
> >> users will be hitting it for the next few years.
> >>
> >> ---
> >>
> >> On another note, I have to admit I'm starting to doubt how well our LT
Hello,
Since I'm not on release-team I'm discovering this just now.
On Wednesday, 12 February 2020 21:59:32 CET Nate Graham wrote:
> [+ 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 C
will be hitting it for the next few years.
---
On another note, I have to admit I'm starting to doubt how well our LTS
Plasma product works without a corresponding LTS frameworks release to
support it. We can fix bugs in software that uses the Plasma release
schedule till the cows come home, but if the bug
This revision was automatically updated to reflect the committed changes.
Closed by commit R120:1967dc08e3db: [Notifications] Release all cookies when
service unregisters (authored by broulik).
CHANGED PRIOR TO COMMIT
https://phabricator.kde.org/D26125?vs=71905=71906#toc
REPOSITORY
R120
broulik created this revision.
broulik added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
broulik requested review of this revision.
REVISION SUMMARY
An application could have multiple inhibitions. Release all of them when the
service unregisters
As a reminder, if you added any new feature to Plasma 5.17 please add it to:
https://notes.kde.org/p/plasma_5_17
so that we have all the information in advance for the people who
write the release text
David
вт, 23 июл. 2019 г. в 19:04, Rik Mills :
>
> On 23/07/2019 16:53, Jonathan Riddell wrote:
>
> > https://community.kde.org/Schedules/Plasma_5
>
> Has someone made changes to how table formatting is done there, or on
> the wiki as a whole? That lack of table lines and borked alignment looks
>
On 23/07/2019 16:53, Jonathan Riddell wrote:
> https://community.kde.org/Schedules/Plasma_5
Has someone made changes to how table formatting is done there, or on
the wiki as a whole? That lack of table lines and borked alignment looks
dreadful.
> Distros, please say if you would like any of
1 - 100 of 549 matches
Mail list logo
