Re: New Application Status
Am 03.12.24 um 09:02 schrieb Ingo Klöcker: On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit Justin Zobel wrote: I'm a bit frustrated by our new application development pipeline. I see applications appear on apps.kde.org and in official namespaces on GitLab before they have passed KDE Review. In my opinion you are conflating two completely different things. Let's discuss them separately. Let's start with apps.kde.org. I feel this is falsely advertising to the world that the app is ready for use. I agree that this could be improved. A possible solution would be to use the brand-new lifecycle attribute in repo-metadata to clearly mark apps that haven't passed KDE Review as beta. I don't think that hiding them from apps.kde.org is a fair solution. On the contrary, I think having beta apps on apps.kde.org could possibly attract the attention of other developers who'd be interested in working on a new app and of beta users who'd be interested in giving the app a try. The possibility to get early feedback is a key value of FOSS. "Release early. Release often." https://community.kde.org/Policies/Application_Lifecycle clearly documents what differentiates playground projects from reviewed projects (although this wiki page needs to be updated to mention the new lifecycle attribute instead of the old projectpath attribute). I think it's just a matter of making this information more visible to avoid wrong expectations. I'd rephrase it around "Does it have a stable release?". If not then we could show it under something like "Beta Applications". That's a more user-relevant criterium than "Did it pass kdereview", which is fairly internal and meaningless to most people. Technically kdereview is a precondition for a stable release, so the end result isn't much different. It would however prevent a situation where the app is technically "reviewed" but there's still no installable release. The button on apps.kde.org that says 'Install on Linux' takes me to Discover and then tells me that the app was not found in any software repositories. Is "passing KDE Review" really connected in any way to "packaged by some distro"? I guess that's a question only distro packagers can answer. It also tells me to report this to my distribution which can lead to noise on distro bug trackers. It can also lead to noise on the KDE bug tracker because a user wants to install the application but can't. Discover probably shouldn't do this for beta apps. I have no idea how the beta state could be communicated to Discover. Is there something suitable in AppStream? I didn't see something obvious; we could probably use tags. To avoid duplicate information this should somehow be added automatically based on the lifecyle attribute in repo-metadata. Discover uses the distributions Appstream pool. If the app is not packaged in the distro Appstream doesn't know about this. As far as I can tell there is no good way for Discover to distinguish between "This app you told me to open doesn't exist" and "it exists but isn't packaged in this distribution". Now GitLab namespaces I think keeping applications in user namespaces until it has passed KDE Review would solve both of these problems. I think keeping applications in user namespaces until they have passed KDE Review is an excellent way to hide them from potential co-contributors. Maybe it's just me because I don't read blogs, follow people on any s.m. and don't scour GitLab user namespaces for interesting projects, but I have never stumbled accidentally over an interesting project hidden in a user namespace. I 100% agree. This proposal would introduce tons of obstacles for collaboration, and I don't see any benefit for it whatsoever. Regards, Ingo Cheers Nico
Re: New Application Status
On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker wrote: > On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit Justin > Zobel wrote: > > I'm a bit frustrated by our new application development pipeline. > > > > I see applications appear on apps.kde.org and in official namespaces on > > GitLab before they have passed KDE Review. > > In my opinion you are conflating two completely different things. Let's > discuss > them separately. > Agreed - one is how we present our software to the world (apps.kde.org) while another reflects how we develop our software. > > Let's start with apps.kde.org. > > > I feel this is falsely advertising to the world that the app is ready > > for use. > > I agree that this could be improved. A possible solution would be to use > the > brand-new lifecycle attribute in repo-metadata to clearly mark apps that > haven't passed KDE Review as beta. I don't think that hiding them from > apps.kde.org is a fair solution. On the contrary, I think having beta > apps on > apps.kde.org could possibly attract the attention of other developers > who'd be > interested in working on a new app and of beta users who'd be interested > in > giving the app a try. The possibility to get early feedback is a key value > of > FOSS. "Release early. Release often." > > https://community.kde.org/Policies/Application_Lifecycle clearly > documents > what differentiates playground projects from reviewed projects (although > this > wiki page needs to be updated to mention the new lifecycle attribute > instead > of the old projectpath attribute). I think it's just a matter of making > this > information more visible to avoid wrong expectations. > We also have this same issue with handling archival / unmaintained status, which ideally should be pulled from the same lifecycle key. At the moment I think there are a couple of different mechanisms within the apps.kde.org generator codebase that determine this - which means that even after an application is marked as unmaintained and archived on GItlab it continues to show up on invent.kde.org. > > The button on apps.kde.org that says 'Install on Linux' takes me to > > Discover and then tells me that the app was not found in any software > > repositories. > > Is "passing KDE Review" really connected in any way to "packaged by some > distro"? I guess that's a question only distro packagers can answer. > > > It also tells me to report this to my distribution which can lead to > > noise on distro bug trackers. It can also lead to noise on the KDE bug > > tracker because a user wants to install the application but can't. > > Discover probably shouldn't do this for beta apps. I have no idea how the > beta > state could be communicated to Discover. Is there something suitable in > AppStream? I didn't see something obvious; we could probably use tags. To > avoid duplicate information this should somehow be added automatically > based > on the lifecyle attribute in repo-metadata. > Would we have beta software that has passed KDE Review? The other thing we could do is suppress / not show the Discover/Appstream URL if it has not passed KDE Review. > > Now GitLab namespaces > > > I think keeping applications in user namespaces until it has passed KDE > > Review would solve both of these problems. > > I think keeping applications in user namespaces until they have passed KDE > Review is an excellent way to hide them from potential co-contributors. > Maybe > it's just me because I don't read blogs, follow people on any s.m. and > don't > scour GitLab user namespaces for interesting projects, but I have never > stumbled accidentally over an interesting project hidden in a user > namespace. > I'll also note that user namespaces are not writable to all developers, while our general purpose namespaces are (unless you explicitly add teams/kde-developers as a developer to your personal project that is). That being said though, we have not really been enforcing certain rules on non-reviewed projects (such as not being allowed to do stable releases, etc) so the benefits of being reviewed aside from qualifying for entry into Frameworks / Gear / Plasma aren't really material. Perhaps we should reinstate that. > Regards, > Ingo > Cheers, Ben
Re: New Application Status
On 2024-12-03, Ingo Klöcker wrote: > Is "passing KDE Review" really connected in any way to "packaged by some > distro"? I guess that's a question only distro packagers can answer. It is not. But "having stable releases" is connected, though if the thing is sufficiently interesting, prereleases and snapshots can be packaged. I do agree that some sort of marking for 'early-in-development'-apps on apps.kde.org does make sense, and maybe that marker should only be removed once we at least have releases, but maybe also have passed kde review. /Sune
Re: New Application Status
On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit Justin Zobel wrote: > I'm a bit frustrated by our new application development pipeline. > > I see applications appear on apps.kde.org and in official namespaces on > GitLab before they have passed KDE Review. In my opinion you are conflating two completely different things. Let's discuss them separately. Let's start with apps.kde.org. > I feel this is falsely advertising to the world that the app is ready > for use. I agree that this could be improved. A possible solution would be to use the brand-new lifecycle attribute in repo-metadata to clearly mark apps that haven't passed KDE Review as beta. I don't think that hiding them from apps.kde.org is a fair solution. On the contrary, I think having beta apps on apps.kde.org could possibly attract the attention of other developers who'd be interested in working on a new app and of beta users who'd be interested in giving the app a try. The possibility to get early feedback is a key value of FOSS. "Release early. Release often." https://community.kde.org/Policies/Application_Lifecycle clearly documents what differentiates playground projects from reviewed projects (although this wiki page needs to be updated to mention the new lifecycle attribute instead of the old projectpath attribute). I think it's just a matter of making this information more visible to avoid wrong expectations. > The button on apps.kde.org that says 'Install on Linux' takes me to > Discover and then tells me that the app was not found in any software > repositories. Is "passing KDE Review" really connected in any way to "packaged by some distro"? I guess that's a question only distro packagers can answer. > It also tells me to report this to my distribution which can lead to > noise on distro bug trackers. It can also lead to noise on the KDE bug > tracker because a user wants to install the application but can't. Discover probably shouldn't do this for beta apps. I have no idea how the beta state could be communicated to Discover. Is there something suitable in AppStream? I didn't see something obvious; we could probably use tags. To avoid duplicate information this should somehow be added automatically based on the lifecyle attribute in repo-metadata. Now GitLab namespaces > I think keeping applications in user namespaces until it has passed KDE > Review would solve both of these problems. I think keeping applications in user namespaces until they have passed KDE Review is an excellent way to hide them from potential co-contributors. Maybe it's just me because I don't read blogs, follow people on any s.m. and don't scour GitLab user namespaces for interesting projects, but I have never stumbled accidentally over an interesting project hidden in a user namespace. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: New Application Status
Hi Probably I'm one of the reasons this discussion started. There is a new project https://invent.kde.org/graphics/karp which passed the review and was moved from incubation to playground. All by the book, I guess. It is already at https://apps.kde.org i.e. but flatpack CI is not yet unlocked. And here we are. Project version is 25.03.70 so a stable release is planned for next spring. But the project already benefited from being at the "official" gitlab repo. Ben will know something about that - thank You by the way. And thank You all in advance. Seems like moving to https://invent.kde.org/graphics speed things up. Kind regards Tomasz On Tue, Dec 3, 2024 at 9:21 AM Ben Cooksley wrote: > > On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker wrote: >> >> On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit Justin >> Zobel wrote: >> > I'm a bit frustrated by our new application development pipeline. >> > >> > I see applications appear on apps.kde.org and in official namespaces on >> > GitLab before they have passed KDE Review. >> >> In my opinion you are conflating two completely different things. Let's >> discuss >> them separately. > > > Agreed - one is how we present our software to the world (apps.kde.org) while > another reflects how we develop our software. > >> >> >> Let's start with apps.kde.org. >> >> > I feel this is falsely advertising to the world that the app is ready >> > for use. >> >> I agree that this could be improved. A possible solution would be to use the >> brand-new lifecycle attribute in repo-metadata to clearly mark apps that >> haven't passed KDE Review as beta. I don't think that hiding them from >> apps.kde.org is a fair solution. On the contrary, I think having beta apps on >> apps.kde.org could possibly attract the attention of other developers who'd >> be >> interested in working on a new app and of beta users who'd be interested in >> giving the app a try. The possibility to get early feedback is a key value of >> FOSS. "Release early. Release often." >> >> https://community.kde.org/Policies/Application_Lifecycle clearly documents >> what differentiates playground projects from reviewed projects (although this >> wiki page needs to be updated to mention the new lifecycle attribute instead >> of the old projectpath attribute). I think it's just a matter of making this >> information more visible to avoid wrong expectations. > > > We also have this same issue with handling archival / unmaintained status, > which ideally should be pulled from the same lifecycle key. > At the moment I think there are a couple of different mechanisms within the > apps.kde.org generator codebase that determine this - which means that even > after an application is marked as unmaintained and archived on GItlab it > continues to show up on invent.kde.org. > >> >> > The button on apps.kde.org that says 'Install on Linux' takes me to >> > Discover and then tells me that the app was not found in any software >> > repositories. >> >> Is "passing KDE Review" really connected in any way to "packaged by some >> distro"? I guess that's a question only distro packagers can answer. >> >> > It also tells me to report this to my distribution which can lead to >> > noise on distro bug trackers. It can also lead to noise on the KDE bug >> > tracker because a user wants to install the application but can't. >> >> Discover probably shouldn't do this for beta apps. I have no idea how the >> beta >> state could be communicated to Discover. Is there something suitable in >> AppStream? I didn't see something obvious; we could probably use tags. To >> avoid duplicate information this should somehow be added automatically based >> on the lifecyle attribute in repo-metadata. > > > Would we have beta software that has passed KDE Review? > > The other thing we could do is suppress / not show the Discover/Appstream URL > if it has not passed KDE Review. > >> >> >> Now GitLab namespaces >> >> > I think keeping applications in user namespaces until it has passed KDE >> > Review would solve both of these problems. >> >> I think keeping applications in user namespaces until they have passed KDE >> Review is an excellent way to hide them from potential co-contributors. Maybe >> it's just me because I don't read blogs, follow people on any s.m. and don't >> scour GitLab user namespaces for interesting projects, but I have never >> stumbled accidentally over an interesting project hidden in a user namespace. > > > I'll also note that user namespaces are not writable to all developers, while > our general purpose namespaces are (unless you explicitly add > teams/kde-developers as a developer to your personal project that is). > > That being said though, we have not really been enforcing certain rules on > non-reviewed projects (such as not being allowed to do stable releases, etc) > so the benefits of being reviewed aside from qualifying for entry into > Frameworks / Gear / Plasma aren't really material. Perh
KDE Gear projects with failing CI (release/24.12) (3 December 2024)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. VERY BAD NEWS: kalzium freebsd job has been failing for 4 consecutive weeks and I've removed the job altogether Good news: 1 repository was fixed Bad news: 2 repositories still failing kdenlive - NEW * https://invent.kde.org/multimedia/kdenlive/-/pipelines/833716 * craft_appimage_qt6_x86_64 job fails kunifiedpush - NEW * https://invent.kde.org/libraries/kunifiedpush/-/pipelines/833247 * connectortest fails on freebsd Cheers, Albert P.S: This is assuming the craft macos job succeed I got tired of waiting
Feedback on KDE Plasma 6 Default Settings: A Call for Reflection
Dear KDE Team, As a long-time user and supporter of KDE, I am writing to express my concern regarding the recent decision to set double-click as the default interaction for opening files and folders in KDE Plasma 6. While I understand the intention of aligning KDE with what may be perceived as mainstream user expectations, this decision seems at odds with the core principles that have always defined KDE: freedom, configurability, and serving the unique needs of its loyal community. Linux users have chosen this platform not because it mimics other operating systems, but precisely because it offers an environment that prioritizes user choice and individuality. Setting double-click as the default behavior may cater to users transitioning from Windows or macOS, but it disregards the preferences of KDE’s long-established user base, many of whom have embraced single-click as a hallmark of KDE’s innovative user experience. This change, though seemingly minor, sends an unfortunate message: that KDE may be prioritizing conformity over its long-standing tradition of empowering users to shape their environment as they see fit. Instead of adopting defaults that resemble other platforms, KDE should continue to showcase its unique strengths—flexibility, customization, and a commitment to open innovation. I urge the KDE team to reconsider this default setting and engage with the community on how such changes impact the user experience. By preserving the spirit of user-centric design, KDE will not only retain its dedicated supporters but also stand as a beacon of choice in the increasingly homogenized world of technology. Thank you for your attention, and I hope this feedback helps guide future decisions. Sincerely, Lucy. S & Linux Community OpenPGP_0x6E889797125BB894.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Feedback on KDE Plasma 6 Default Settings: A Call for Reflection
On 4/12/24 01:52, Lucy wrote: Dear KDE Team, As a long-time user and supporter of KDE, I am writing to express my concern regarding the recent decision to set double-click as the default interaction for opening files and folders in KDE Plasma 6. While I understand the intention of aligning KDE with what may be perceived as mainstream user expectations, this decision seems at odds with the core principles that have always defined KDE: freedom, configurability, and serving the unique needs of its loyal community. Linux users have chosen this platform not because it mimics other operating systems, but precisely because it offers an environment that prioritizes user choice and individuality. Setting double-click as the default behavior may cater to users transitioning from Windows or macOS, but it disregards the preferences of KDE’s long-established user base, many of whom have embraced single-click as a hallmark of KDE’s innovative user experience. This change, though seemingly minor, sends an unfortunate message: that KDE may be prioritizing conformity over its long-standing tradition of empowering users to shape their environment as they see fit. Instead of adopting defaults that resemble other platforms, KDE should continue to showcase its unique strengths—flexibility, customization, and a commitment to open innovation. I urge the KDE team to reconsider this default setting and engage with the community on how such changes impact the user experience. By preserving the spirit of user-centric design, KDE will not only retain its dedicated supporters but also stand as a beacon of choice in the increasingly homogenized world of technology. Thank you for your attention, and I hope this feedback helps guide future decisions. Sincerely, Lucy. S & Linux Community Hi Lucy, As you've mentioned this is only a default settings. KDE users are still empowered to make their own choices in the Settings. This settings is even considered important enough to be on the Quick Settings page which is the first to appear. Justin
Re: New Application Status
El dimarts, 3 de desembre del 2024, a les 10:26:35 (Hora estàndard del Centre d’Europa), Tomasz Bojczuk va escriure: > Hi > > Probably I'm one of the reasons this discussion started. > There is a new project https://invent.kde.org/graphics/karp which > passed the review and was moved from incubation to playground. Naming maters here, karp did pass "incubation" not really [code/functionality] "review". That is, me as "incubation sponsor" only looked at the "logistical" aspects, if you look at https://invent.kde.org/graphics/karp/-/issues/1 you will see all the checks are about licensing/manifesto/workflow/etc. I did not look at all if the code was good or if it would eat your files, that's what we have the "kdereview" step for. The "kdereview" step is mandatory (unless changed and I forgot) for making a release from kde.org servers. > All by the book, I guess. > It is already at https://apps.kde.org i.e. but flatpack CI is not yet > unlocked. And here we are. > > Project version is 25.03.70 so a stable release is planned for next spring. Are you aiming for inclusion in KDE Gear? (The number may seem you're aiming for that but also you may not). Cheers, Albert > But the project already benefited from being at the "official" gitlab repo. > Ben will know something about that - thank You by the way. > And thank You all in advance. > Seems like moving to https://invent.kde.org/graphics speed things up. > > Kind regards > Tomasz > > On Tue, Dec 3, 2024 at 9:21 AM Ben Cooksley wrote: > > On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker wrote: > >> On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit > >> Justin > >> > >> Zobel wrote: > >> > I'm a bit frustrated by our new application development pipeline. > >> > > >> > I see applications appear on apps.kde.org and in official namespaces on > >> > GitLab before they have passed KDE Review. > >> > >> In my opinion you are conflating two completely different things. Let's > >> discuss them separately. > > > > Agreed - one is how we present our software to the world (apps.kde.org) > > while another reflects how we develop our software.> > >> Let's start with apps.kde.org. > >> > >> > I feel this is falsely advertising to the world that the app is ready > >> > for use. > >> > >> I agree that this could be improved. A possible solution would be to use > >> the brand-new lifecycle attribute in repo-metadata to clearly mark apps > >> that haven't passed KDE Review as beta. I don't think that hiding them > >> from apps.kde.org is a fair solution. On the contrary, I think having > >> beta apps on apps.kde.org could possibly attract the attention of other > >> developers who'd be interested in working on a new app and of beta users > >> who'd be interested in giving the app a try. The possibility to get > >> early feedback is a key value of FOSS. "Release early. Release often." > >> > >> https://community.kde.org/Policies/Application_Lifecycle clearly > >> documents > >> what differentiates playground projects from reviewed projects (although > >> this wiki page needs to be updated to mention the new lifecycle > >> attribute instead of the old projectpath attribute). I think it's just a > >> matter of making this information more visible to avoid wrong > >> expectations. > > > > We also have this same issue with handling archival / unmaintained status, > > which ideally should be pulled from the same lifecycle key. At the moment > > I think there are a couple of different mechanisms within the > > apps.kde.org generator codebase that determine this - which means that > > even after an application is marked as unmaintained and archived on > > GItlab it continues to show up on invent.kde.org.> > >> > The button on apps.kde.org that says 'Install on Linux' takes me to > >> > Discover and then tells me that the app was not found in any software > >> > repositories. > >> > >> Is "passing KDE Review" really connected in any way to "packaged by some > >> distro"? I guess that's a question only distro packagers can answer. > >> > >> > It also tells me to report this to my distribution which can lead to > >> > noise on distro bug trackers. It can also lead to noise on the KDE bug > >> > tracker because a user wants to install the application but can't. > >> > >> Discover probably shouldn't do this for beta apps. I have no idea how the > >> beta state could be communicated to Discover. Is there something > >> suitable in AppStream? I didn't see something obvious; we could probably > >> use tags. To avoid duplicate information this should somehow be added > >> automatically based on the lifecyle attribute in repo-metadata. > > > > Would we have beta software that has passed KDE Review? > > > > The other thing we could do is suppress / not show the Discover/Appstream > > URL if it has not passed KDE Review.> > >> Now GitLab namespaces > >> > >> > I think keeping applications in user namespaces until it has passed KDE > >> > Review would
KDE Gear projects with failing CI (master) (3 December 2024)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. VERY BAD NEWS: kalzium freebsd job has been failing for 4 consecutive weeks and I've removed the job altogether Good news: 2 repositories were fixed Bad news: 2 repositories started failing kdenlive - NEW * https://invent.kde.org/multimedia/kdenlive/-/pipelines/833721 * craft_appimage_qt6_x86_64 job fails kimap - NEW * https://invent.kde.org/pim/kimap/-/pipelines/832807 * testsession fails on freebsd Cheers, Albert P.S: This is assuming the craft macos job succeed I got tired of waiting
