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

[Nate Graham]

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
thing if I trust its CMakeLists.txt. It has Baloo as a recommended but
optional dependency, and disable it altogether for Win32 builds.


Yes, Elisa also includes an internal indexer, for use on Windows and 
Android, or on *Nix when Baloo isn't installed or is disabled.


I think the original idea for the app was to delegate all the indexing 
heavy lifting to Baloo to avoid internal complication, but clearly this 
has not worked out in practice, since to be truly cross-platform, it 
can't assume that Baloo is present and active and does need its own 
indexer. So maybe the best course of action is actually to remove Baloo 
support entirely and always use the internal indexer, so that we don't 
have two different code paths.


Nate

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

[Nate Graham]

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 sense to move Baloo, too, 
given it only

is usable with the daemon inside Plasma more or less, too?

Greetings
Christoph


Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make 
them haul in Plasma stuff.


Nate

Re: Planning the final 6 release timeframes

[Nate Graham]

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

[Nate Graham]

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
53940a920773a105df0af9dd3dbf7afcebc6e1eb66404cc77f46c80563b4ada1  
sources/plasma-framework-5.100.1.tar.xz

Linux/BSD packagers: you can skip kconfig-5.100.1, that fix is Windows-only 
anyway.



Thanks a lot, David!

Nate

New

[Nate Graham]

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 that I'd like to recommend we make new 
releases of the kconfig and plasma-framework frameworks so we can get 
the fixes to users as quickly as possible.


Would that be possible to do?

Nate

Re: KF 5.95-rc1 delayed

[Nate Graham]

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? Thanks! :)

with that included, I think we'll finally be done from the 
plasma-framework perspective.


Nate

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

[Nate Graham]

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 problem will recur infinitely because 
people will continue to miss or ignore CI failures because they send 
emails after merge/commit rather than before, and are formatted 
semi-incomprehensibly.


Nate


On 6/16/21 12:28 PM, Ben Cooksley wrote:

Hi all,

The following is notice that I intend to withdraw CI services from the 
following two KDE projects due to faults in their code or build system 
which are having a significant adverse impact on the CI system and 
negatively impacting on other projects:


- KDevelop
- KDE Connect

This withdrawal will be applied to all platforms.

In the case of KDevelop, it has a series of unit tests which on FreeBSD 
cause gdb to hang and consume an entire CPU core indefinitely. This 
slows down builds for all other projects using that CI server, and also 
prevents KWin tests from proceeding - completely blocking it's jobs. 
This fault is in the debuggee_slow family of tests.


As this issue has persisted for some time now despite being mentioned, I 
require that the family of tests in question be disabled across all 
platforms.


In the case of KDE Connect, as part of it's configure process it runs an 
external command that results in dbus-daemon being launched. This 
process persists following the build and would only be cleaned up by our 
tooling that runs tests. Should the compilation fail (as it does 
currently) it will result in the CI builder being broken - which is why 
we have had so many Windows builds fail lately.


As this is an issue that has occurred previously, I require that the 
configure time check which is launching dbus-daemon to be expunged from 
KDE Connect.


As a reminder to all projects, running commands that interact with 
dbus-daemon or kdeinit is not permitted during configure or build time.


Regards,
Ben Cooksley
KDE Sysadmin

Re: github pull requests are piling up

[Nate Graham]

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 
dedicate to it (it's written in go which I'm not very proficient at and it 
seems that there have been github and google appengine API changes).

If someone wants to try to look at it together with me ping me and we can have 
a look, if not i'll shut it down at some point, it's costing me like 0,01€ a 
month that is kind of unjustifiable given that it does nothing :D

Bot code is at https://github.com/tsdgeos/nopullrequests


Ok, Shantanu seems to have fixed it :)


Very nice! Good to see an automated solution to the problem.

Nate

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

[Nate Graham]

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 evening i've completed updates to the Windows CI system, bringing 
it from the previous Qt 5.14 setup it was using up to the more recent Qt 
5.15. As part of this various other libraries will have also been updated.


This update was prompted by an unannounced dependency change within 
Breeze Icons. As a reminder to all developers, it is imperative that any 
change to your dependencies on a non-KDE project be announced two weeks 
or more in advance.


Unfortunately due to regressions within Breeze Icons, it is not possible 
for the Dependency Builds to complete at this time, meaning Windows CI 
functionality will be generally unavailable until this is corrected.


The failure log can be found at 
https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console


Once the Breeze Icons failure has been corrected, we expect to be able 
to resume normal CI service for Windows.


Regards,
Ben Cooksley
KDE Sysadmin

Re: KEmoticons, emoticons kcm

[Nate Graham]

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
around for the few apps that might still use it (ktp? kopete?) could
make sense, I'm afraid it's probably making it confusing for the users
who expect this to actually allow them to customise their  but
won't.

Do you think it would make sense to deprecate the framework and remove the KCM?

If some application still uses it, they can integrate the kcm
temporarily until their users come to terms that  is the new :).


I think so. IIRC we already agreed to this, in fact. See 
https://phabricator.kde.org/T11585


Nate

Re: Request for ktexteditor patch release

[Nate Graham]

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

Am Freitag, 15. Mai 2020, 12:03:08 CEST schrieb David Faure:

On vendredi 15 mai 2020 11:01:04 CEST Friedrich W. H. Kossebau wrote:

Hi,

I would like to ask for a 5.70 patch release for ktexteditor, with
972da14f486a83556e192d09bb18a2500728895a cherry-picked.

Not a crasher, but preventing the pickup of any global view setting
changes
after a kate/kdevelop session close & open cycle for existing document
views, which has been hit and reported by a few people already the last
days.


Thanks for the notification. Done:

ktexteditor v5.70.1
5e6ea19f95a36e21473c00a8d30cbea0f150a13f
c7b568e75c147161992f8875fe36fb46885bccddb63c22edaf81071583f4204c
sources/ktexteditor-5.70.1.tar.xz


Merci.


Please add a description of the bug in www/info/kde-frameworks-5.70.0.php
(or give me a patch if you can't push).


No checkout of the respective repo, so possibly fastest if I give you the raw
data here:
* KTextEditor global view setting changes ignored after session reopening
(Kate, KDevelop)
https://bugs.kde.org/show_bug.cgi?id=421375


Also, please make sure to write a unittest for this regression so we catch
it next time.


Yup.

Cheers
Friedrich

Re: Adding a patch to 5.70

[Nate Graham]

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 Plasma themes, and as Nate
explained "If this doesn't land in Frameworks 5.70, Plasma 5.19 users run
the risk of being hit by it, as 5.70 is the frameworks dependency for that
Plasma release."


OK, done:

plasma-framework v5.70.0-rc2
fe45d59e250d1c7f4579f54fec52437ebb0e5d03
cb8289d495e4df19056ce8814dacd8a0afe93bff1edb0352028c6b6e47364ba5  
sources/plasma-framework-5.70.0.tar.xz

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

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 allows for a global listing only.
Are you saying that if we put plasma-framework in Plasma and share it 
with the Plasma group, then its MRs won't show up in the Plasma group's 
MR list? And that if we put it in the Plasma group and share it with the 
Frameworks group, then its MRs won't show up in the Frameworks group's 
MR list?


If so, that seems like it defeats one of the points of sharing a 
project/repo across groups. :(


Is this fixed in EE, or is it just a bug affecting all versions?

Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

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 is a dedicated setting for
it: `ignore-kde-structure`. Kinda does what it says on the tin ;)


Yes, and this setting is set by default. :)

Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

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

[Nate Graham]

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 folder.
This would allow for example:

- frameworks/kcoreaddons on Gitlab continues to be called
'kcoreaddons' in your local checkout folder
- maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder

This allows for the URLs on Gitlab to make sense, while simultaneously
allowing your local source checkout folders to continue to work in the
manner in which they do currently.
Note that we do not expect people to hit this in many cases - this is
about giving us the flexibility for the long term without imposing
unnecessary bureaucracy and limits on projects within the KDE
umbrella.

Automated tooling such as kdesrc-build and the proposed clone script
(that searches in namespaces) should be able to handle this without
much issue.
In the case of manually done clones, it is reasonable to expect people
to know what they're doing with their clones, and name them
appropriately in the event they have a collision.

Does this sound acceptable?


A little weird, but probably acceptable. I suppose it's no worse than 
having discover build an executable called "plasma-discover", which 
trips me up like five times a day :)


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

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 
repos into ~/kde/src without any of the levels of hierarchy. This would 
seem to require unique repo names, no?


The group categorization we've been discussing may be useful on the web 
UI for newcomers, but it has no value for your source checkout folder 
IMO, where it just makes it slightly more annoying to navigate from one 
repo to another.


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

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, presumably our infrastructure 
would do the right thing the first time and you wouldn't need to use any 
migration script, right?


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

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


- kdesrc-build and other scripts can be updated to allow people to 
easily check out repos using git prefixes (e.g. so that something like 
`git clone kde:dolphin` will still work regardlyss of a project's 
underlying group)


- cgit will continue to exist for three weeks to provide some transition 
time


- Each repo can have its own workboard in addition to the single 
group-level workboard


If the above are accurate, then I firmly support the proposal.

As for the actual grouping, I think it makes sense to have top-level 
groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can 
support putting apps into category-specific groups (e.g. Multimedia, 
Office, Graphics, Games, etc) as long as apps could appear in multiple 
groups if needed for the case of apps that logically span boundaries 
(e.g. repos for PlaMo apps could appear in both the Plasma Mobile 
top-level group and also the relevant app group).



Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:52 AM, Nate Graham wrote:

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde 
to all)
and then have every subcommunity decide for themselves which repos 
they want

to see in their group.


If this is possible, it seems like the best solution to me.



I've just been informed that it's possible to have a project appear in 
multiple groups such that I could find plasma-frameworks in both the 
Frameworks and Plasma top-level groups.


Therefore I rescind my objection and endorse having many top-level 
groups instead of a single flat top-level namespace, provided that we do 
put projects that are related to multiple groups into those multiple groups.


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde to all)
and then have every subcommunity decide for themselves which repos they want
to see in their group.


If this is possible, it seems like the best solution to me.

Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 4:38 AM, Aleix Pol wrote:

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?


Trying to categorize everything into a single group cannot succeed 
because many projects could logically belong to multiple groups (e.g 
plasma-framework is a framework that's a part of Plasma; Discover is an 
app that's a part of Plasma; kdenetwork-filesharing and kio-extras are 
libraries that are distributed via the apps release service). I foresee 
endless pointless arguments about the best group for something to live in.


Let's step back: do we have to put every repo inside a group in the 
first place? Is it solely so you can look at a nice list of all open 
merge requests for PIM/Frameworks/etc? If so, perhaps this workflow 
could be approximated with tags instead or group assignments instead


We create many very granular groups for the purposes of organizing teams 
and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, 
Krita, Dolphin, Okular, VDG, etc.) and then every new merge request 
could receive a tag or assignee corresponding to its relevant code 
review groups (e.g. merge requests for kio and kio-extras could get get 
tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs 
could get tagged with both "Plasma" and "Frameworks", and so on).


So +1 for a single top-level group I suppose.

Nate

Re: Update on Status of Gitlab Migration

[Nate Graham]

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 most 
intuitively obvious domain name rather than some arbitrarily different one.


No matter what, we're all going to be talking about "KDE GitLab" or 
"KDE's GitLab instance". The title of the relevant documentation page is 
"GitLab" (much as the Phabricator documentation page was named 
"Phabricator"). And when the migration is complete, we're all going to 
announce that "KDE is now using GitLab!" So the cat's out of the bag on 
using the word "GitLab" and avoiding some number of people looking for 
our stuff at gitlab.com and not finding it there. invent.kde.org doesn't 
avoid that at all.


Given that, which is more confusing: explaining to people that we have a 
GitLab instance at invent.kde.org, or explaining to people that we have 
a GitLab instance at gitlab.kde.org?


I know that over the next few years I'm going to be directing hundreds 
of people towards our infrastructure, and I would rather be able to say 
"please submit a pull request at gitlab.kde.org" rather than "please 
submit a pull request at KDE's GitLab instance at invent.kde.org."


I know this probably feels like annoyingly extreme bikeshedding, but, I 
dunno, names are important.


Nate

Re: Update on Status of Gitlab Migration

[Nate Graham]

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.


Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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 not apply to parts 
of the stack that we do control. Improvement is possible even when 
perfection is not.




Incidentally what happens is that those libraries are not buggy, and it seems 
the Plasma-facing parts of KF5 are, well, let's make them not be.


Agreed. Everyone wants less buggy releases.

However "less buggy releases" does not fully solve the problem for LTS 
distros that freeze their KF version. Without point releases of the 
version they freeze on, we are unable to ship fixes for regressions that 
do sneak in, and we are unable to ship fixes for old or longstanding 
issues that we find a way to fix later. We can do both of these things 
with Plasma. We cannot do either with Frameworks. That's the problem.


Ultimately I think we need to decide whether we want to fully support 
the Plasma LTS or can it. Right now we're in this awkward position where 
we can hand packagers tarballs with bugfix point releases of Plasma, but 
not Frameworks. Ultimately this means that there's a class of bug that 
just doesn't get fixed in the distros with LTS Plasma, which in the end 
makes us look bad.


Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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? ;)  I merely say that going "Neon or
else unsupported" is a very downstream-hostile attitude,


...And where did I say that in my reply? ;) I think we should absolutely 
continue to support all downstreams, not just Neon; that would be crazy! 
:) This is in fact why I'm advocating for an LTS 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 argue 
about what packagers should do, but the best way to get them to do that 
is to make it easy for them. :)




(Neon suffers from the same "LTS problem" for everything that's not KDE-made
software, FTR, but that's not the issue I want to raise here)


Indeed, and that's the reason why I'm happy with Tumbleweed. I'm quite 
on board with the seemingly prevailing opinion that discrete LTS 
releases amount to a broken, defective model. It's just that for the 
time being we have a product explicitly catering to distros using that 
broken, defective model. It just seems like an awkward situation that 
should be addressed one way or another, not left in tension indefinitely.


Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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 distributions simply backport
important bug fixes for KF themselves, kind of maintaining their own KF LTS
version of the KF version they pinpointed to when they froze the ingredients
to their OS. Because they are used to do this for other projects as well, and
so miss this could be done in cooperation with upstream.


There has been pain. This thread mentions a number of examples, and 
There were quite a few for the last 5.12 LTS too. But more generally, 
the pain is baked into Frameworks due to the lack of any bugfix 
releases. For example Kubuntu 18.04 shipped with the Plasma 5.12 LTS and 
Frameworks 5.44. That Plasma version has continued to receive bugfix 
point releases since then. But the Frameworks product has not, and so 
users have now missed out on two years worth of bugfixes. I don't know 
about openSUSE, but I know that Kubuntu does not have the resources to 
backport individual KF bugfixes--I repeatedly requested this as I 
identified them and none ever got backported. But they do ship point 
releases for Plasma, so they could ship point releases for an LTS 
Frameworks version.




IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
team up 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 the KF version which 
happens to be the dependency for a Plasma LTS release could have bugfix 
releases? Would that be reasonable?



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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 distributions simply backport
important bug fixes for KF themselves, kind of maintaining their own KF LTS
version of the KF version they pinpointed to when they froze the ingredients
to their OS. Because they are used to do this for other projects as well, and
so miss this could be done in cooperation with upstream.


There has been pain. This thread mentions a number of examples, and 
There were quite a few for the last 5.12 LTS too. But more generally, 
the pain is baked into Frameworks due to the lack of any bugfix 
releases. For example Kubuntu 18.04 shipped with the Plasma 5.12 LTS and 
Frameworks 5.44. That Plasma version has continued to receive bugfix 
point releases since then. But the Frameworks product has not, and so 
users have now missed out on two years worth of bugfixes. I don't know 
about openSUSE, but I know that Kubuntu does not have the resources to 
backport individual KF bugfixes--I repeatedly requested this as I 
identified them and none ever got backported. But they do ship point 
releases for Plasma, so they could ship point releases for an LTS 
Frameworks version.




IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
team up 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 the KF version which 
happens to be the dependency for a Plasma LTS release could have bugfix 
releases? Would that be reasonable?



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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 solutions, in particular because
this failing is entirely upstream. We have already plenty in FOSS, I don't
want KDE to be yet another community that "adopts" them.

"We messed up so let's make things our way" is not an acceptable approach.


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 
laptops that people can and do buy. My wife has it installed on her 
computer. It's an OS as much as any other Ubuntu-derived distro can be 
considered an OS.


I actually happen to use openSUSE Tumbleweed myself instead of Neon for 
a variety of reasons, and I'm happy with it. I'm not saying "Neon is an 
OS!" because I think everyone should immediately switch to it and stop 
using other distros. There's room in the universe of KDE distros for one 
more that happens to be a first-party product--as evidenced by the fact 
that Neon has existed for four years and the whole world hasn't come 
tumbling down. I mean, Microsoft got into the PC hardware business in 
competition with Dell, HP, Toshiba, et al, and it didn't destroy their 
business. Far from it: the new entries from Microsoft spurred everyone 
else to improve their own offerings, broadly lifting the quality of PC 
hardware for everyone.


Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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.


We already do this: it's called the Plasma LTS product. :-) It's been 
specifically created to cater to various distros' desires for an 
extended-support product they can ship to users of their own LTS releases.


But yes, I can also agree with more tests, better stability, moving to 
GitLab so 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 is built around a rolling release model with no bugfix releases at 
all.


If we don't want to change the incompatible way that Frameworks plugs 
into an LTS Plasma release, and we think our opinions regarding how a 
distro ought to ship software are valid, then I think it's time for us 
to take the lead and produce a real reference distro that shows how *we* 
think KDE software should be presented to users. Basically, we 
acknowledge that Neon is already an actual OS--the "KDE OS"--and we 
treat is as such, explicitly advertising it as a fully supported OS 
suitable for users to install and vendors to ship hardware with (as in 
fact Slimbook already does!). See also https://phabricator.kde.org/T12707.


If we don't want to be so opinionated regarding how software should be 
released--perhaps out of fear of alienating sponsors that produce LTS 
distros, for example--then maybe it's time to swallow our opinions, 
respect the way that those distro partners currently ship software even 
if we disagree with it, and adjust Frameworks to better support the 
needs of their LTS releases.



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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 have had
a release-day dependency of 5.67)

The release of Plasma should then take place shortly after the
Frameworks version you have a release-day dependency on.

You stagger it like this to ensure that developers are performing a
full burn in of the Frameworks version for several weeks on their
systems, and to ensure that all the problems they find end up in the
Frameworks that users will have on their systems.


None of this makes a difference for distros that ship LTS Plasma don't 
ship newer Frameworks versions. No matter how much testing you do, some 
bugs in Frameworks will slip through and need to be fixed after the 
release. But the frameworks release cycle has no concept of the 
post-release bugfix like Apps and Plasma do; instead the expectation is 
that the distro will just ship a new Frameworks version in a month. This 
expectation does not match the reality for the distros that want to ship 
an LTS plasma version and do not ship newer Frameworks versions.




As for the distributions that are refusing to update Frameworks, do
you have a list of those distributions?
If they're providing a poor experience to our users then we at the
very least should ensure we steer people away from them.


Oh, you know, just some weird, unimportant little ones, like Debian, 
Ubuntu/Kubuntu, and openSUSE Leap. ;-) We should definitely make sure 
that our users don't use *those*; it's not like they're the big heavy 
hitters of the Linux world that are used in large numbers by 
corporations and shipped on hardware or anything. :)


Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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.


But did people care about all of this? Nope. We had a wallpaper contest 
that was explicitly scheduled to go in even after the Beta. This is 
unacceptable and next time we do this I will flat out revert a wallpaper 
change after the beta.


I agree, we could have and should have done the wallpaper competition 
earlier. However I'm not aware of any user-visible regressions that 
stemmed from the last-minute shuffle for the wallpaper, which is what 
I'm talking about here. Are you?



Next is this pointless scroll bar visual change. Why did that have to go 
in a day before the Beta, 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 and this is a feature that must be spot-on 
and work 120% from day one. The KNewStuffQuick stuff was a substantial 
change even after Beta freeze...


Like the wallpaper shuffle, I'm not aware of any actual user-visible 
bugs that resulted from this.


In my estimation, the last-minute changes were necessary to get us to 
that 120%, or at least closer than where we were before. Without those 
last-minute kuserfeedback changes, I was worried that the poor 
presentation of what was being transmitted would cause a PR disaster, 
send privacy-conscious people into a panic, and cause other users to 
lose trust in us. As-is, we got one guy on Reddit who wouldn't pipe down 
about it. Without the last-minute changes, I foresaw that times a 
hundred. So at that point it was either introduce last-minute changes or 
punt the whole feature into Plasma 5.19. Which we could have done I 
guess. Maybe we should have. But it seemed like a lot of people really 
wanted it in the LTS release.


And again, nothing actually regressed from that, to my knowledge. What I 
was drawing attention here were regressions and bugs introduced in 
Frameworks that affected people upgrading to Plasma 5.18, such as:


- https://bugs.kde.org/show_bug.cgi?id=417351 [FormLayout positioning 
and width regressions]

- https://bugs.kde.org/show_bug.cgi?id=417127 [Can't turn off Baloo]
- https://bugs.kde.org/show_bug.cgi?id=417511 [Un-maximized dark panels 
have white corners]


Without special point releases or distro packager backporting, LTS users 
could be hitting these issues for years.



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

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 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.18 has a minimum Frameworks dependency of 5.66. See 
https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series


The problem here isn't so much API breaks but rather major bugs and UI 
regressions. if a framework has a very visible bug or UI regression in 
5.66 of the kind that we would really like to fix, but LTS distros 
freeze on that version, then LTS users will be stuck with that issue 
forever unless we make a frameworks point release or cajole distro 
packagers to backport the fix.


Rolling release distro users will first see Plasma 5.18 with Frameworks 
5.67, so if that frameworks version has a major bug or UI regression, it 
will take a month for the fix to land in users' hands whereas if the 
issue were in Plasma itself, we could fix it immediately and users would 
get the fix in a week (the first point release is one week after the .0 
release).


My point is that the schedules just don't really match up if we want to 
present a polished finished product and continue to fix bugs for the 
lifetime of an LTS release.



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

[+ 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 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 is in Frameworks, users
are stuck with it forever since LTS distros don't typically ship new
Frameworks releases.

Yes yes, they should, and all that--but they don't.

It seems like we either need to:
- Work on convincing these distros to ship Frameworks versions in a
rolling manner to their LTS users
- Provide an LTS Frameworks product that can receive bugfixes and get
point releases, to support the Plasma LTS product
- Stop misleadingly offering a Plasma LTS product, since everything in
it that comes from Frameworks isn't actually LTS


This should not matter, Plasma LTS is built on *lots* of other libraries that 
are not LTS either.

If it matters is because the quality of KF5 releases are not good, that's what 
should be fixed IMHO.


Yes, the Frameworks 5.67 release was indeed was quite buggy and 
regression-filled from a Plasma perspective :(


However buggy releases are the proximate cause, not the root cause. We 
have to ask: what causes buggy releases?


I would argue that bugginess is baked into the Frameworks product by 
virtue of its very fast one-month release cycle and lack of beta 
periods, as there are for apps and Plasma. No matter how diligent patch 
review is, regressions always sneak in; that's why QA and beta-testing 
exist.


However because Frameworks has no explicit beta period, the only people 
performing QA are those who live on master all the time. The amount of 
time for these people to catch regressions can be as short as one day, 
for changes committed right before tagging. Even for commits at the very 
beginning of a Frameworks release cycle, there will be a maximum of one 
month before they ship to users. There simply isn't enough time to 
provide adequate QA for Frameworks releases, and the pool of people 
doing it is too small.


Making users be the QA is mostly okay for rolling release distros whose 
users are willing to take on that role: regressions get found and fixed 
in the next version and users receive the fixes in one month. But this 
model breaks down for LTS release distros that freeze on a specific 
frameworks version. If the version they've frozen on is buggy, that's 
it. It's buggy forever, unless their we make point releases or their 
already overworked packagers go out of the way to search for and 
backport fixes.


The Frameworks release model just doesn't fit for discrete release 
distros, especially for the LTS releases. Sometimes it works out better 
than other times, but it is a fundamental incompatibility when the 
product wants customers to ship new releases continuously, but the 
customers want the product frozen to one version with only safe bugfixes 
shipped after that.


Personally I think a lengthier release cycle and discrete beta periods 
would really help Frameworks, even in the absence of interest in 
creating a product more aligned to our LTS-using customers.


Nate

Re: Frameworks 5.67 re-spin request

[Nate Graham]

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/kirigami.git/commit/?id=f695cde36a6829b8b92b2fd82deff16
d9385fcb9

https://cgit.kde.org/qqc2-desktop-style.git/commit/?id=6995b4ae81a2f3ca3c24d
2fa6d1560bfe0898737

These commits fix highly user-visible issues with scrollbars in
QML-based apps, most notably Discover.

I've been told that most LTS distros are planning to ship Plasma 5.18
with Frameworks 5.67, so if that version doesn't include these fixes,
then Plasma 5.18 LTS users will be stuck with the issues for years and
we'll get a ton of bug reports.


Done:

kirigami v5.67.1
b0f31c4c671f3cb4cab3425f5d757c6cf6e2d02b
0311ba00b213a26acddd9fe4ce0642ed2500a076429ea5fe4424fdf634f12e68  
sources/kirigami2-5.67.1.tar.xz

qqc2-desktop-style v5.67.1
a992466f2fe596b1ae34da91fd7e95e21b973a52
b2af96084e85096506cc109634234150cfc88a9fcf2d6887c55ef1787c046a44  
sources/qqc2-desktop-style-5.67.1.tar.xz

https://kde.org/info/kde-frameworks-5.67.0.php updated (without much polish).

Frameworks 5.67 re-spin request

[Nate Graham]

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

https://cgit.kde.org/qqc2-desktop-style.git/commit/?id=6995b4ae81a2f3ca3c24d2fa6d1560bfe0898737

These commits fix highly user-visible issues with scrollbars in 
QML-based apps, most notably Discover.


I've been told that most LTS distros are planning to ship Plasma 5.18 
with Frameworks 5.67, so if that version doesn't include these fixes, 
then Plasma 5.18 LTS users will be stuck with the issues for years and 
we'll get a ton of bug reports.


Thanks in advance for the consideration!

Nate

Re: CI system maintainability

[Nate Graham]

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 followed, 
but usually in these circumstances, existing rules or conventions were already 
being violated. So adding new ones usually doesn't help as much as people would 
want because they don't address the underlying issue of why rules are being 
broken in the first place.

In this case, it seems like the problem is that there are certain individuals 
or teams that are pushing risky, breaking changes without code review, and then 
ignoring failures in the CI. I think we might do well to try to answer the 
question of why that's happening before we create a new rule aimed at stopping 
it.

Nate

Re: KDE file dialog column resize no longer possible?

[Nate Graham]

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 sectionResized slot will check if the QTreeView contains a positive number of 
elements, if the new size is positive and if the current resize mode is not already 
"Interactive". If so, it sets the current section to interactive resize and 
sets the new size explictly.
- somehow this per-column change does not have the intended effect (when done 
here, with Qt 5.9 and FW 5.52.0), so a class state variable is toggled too
- at an appropriate moment the entire QHeaderView is set to interactive mode if 
that state variable is true. The first QPaintEvent should come after the 
section widths have been determined and turns out to be just in time to get 
actually resizable sections.

I haven't checked in depth if there are side-effects but this works good enough 
for me (as a first draft). The only thing I'd like to see added is the 
persistence of the column widths I mentioned earlier: save the widths of any 
columns the user resized manually, and use those values when the dialog is 
reopened.

Let me know what you think; should I put this on phab?

R.

Re: KDE file dialog column resize no longer possible?

[Nate Graham]

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 
https://cgit.kde.org/kio.git/commit/?id=f28e343063783c6a0a6b925a390a1a1a5e10d91c

But it had to be reverted in 
https://cgit.kde.org/kio.git/commit/?id=9f1b7e879fd2a8e315e564a47e147d90760b0786
 because it caused an unacceptable performance regression.

Essentially what we want to do is auto-size the columns when there's enough 
horizontal space to show everything (i.e. provide a good default view without 
the need for manual adjustment), but when horizontal space is limited, we want 
to ensure that the Name column retains its automatically-determined width and 
give the whole view a scrollbar. I tried a few ways to accomplish this but 
eventually ran into a Qt bug: https://bugreports.qt.io/browse/QTBUG-1248

Assistance would be appreciated. :-)

Nate 


  On Fri, 18 Jan 2019 03:20:26 -0700 René J.V. Bertin  
wrote  
 > Hi, 
 >  
 > Sorry for cross-posting (initially), I'm not certain which list is the most 
 > appropriate. 
 >  
 > It's often been tricky to trigger column resize mode in the KDE file dialog 
 > (when in one of the detailed view modes) but I realise I haven't been able 
 > to do this at all for a little while now. I just checked a Qt example, this 
 > is not a regression in the Qt version I'm using. 
 >  
 > Has resizing support been turned off in KF5 maybe, and if so, where and why? 
 >  
 > Thanks, 
 > René 
 > 

Re: KDE file dialog column resize no longer possible?

[Nate Graham]

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 
https://cgit.kde.org/kio.git/commit/?id=f28e343063783c6a0a6b925a390a1a1a5e10d91c

But it had to be reverted in 
https://cgit.kde.org/kio.git/commit/?id=9f1b7e879fd2a8e315e564a47e147d90760b0786
 because it caused an unacceptable performance regression.

Essentially what we want to do is auto-size the columns when there's enough 
horizontal space to show everything (i.e. provide a good default view without 
the need for manual adjustment), but when horizontal space is limited, we want 
to ensure that the Name column retains its automatically-determined width and 
give the whole view a scrollbar. I tried a few ways to accomplish this but 
eventually ran into a Qt bug: https://bugreports.qt.io/browse/QTBUG-1248

Assistance would be appreciated.  :-)

Nate


  On Fri, 18 Jan 2019 03:20:26 -0700 René J.V. Bertin  
wrote  
 > Hi, 
 >  
 > Sorry for cross-posting (initially), I'm not certain which list is the most 
 > appropriate. 
 >  
 > It's often been tricky to trigger column resize mode in the KDE file dialog 
 > (when in one of the detailed view modes) but I realise I haven't been able 
 > to do this at all for a little while now. I just checked a Qt example, this 
 > is not a regression in the Qt version I'm using. 
 >  
 > Has resizing support been turned off in KF5 maybe, and if so, where and why? 
 >  
 > Thanks, 
 > René 
 >